Oracle v. Google: How Can Your Protect APIs?

(1)

Hubbard

ip

Oracle v. Google: How Can Your Protect APIs?

Dallas Bar Association

Computer Law Section October 22, 2012

Marc A. Hubbard Hubbard Law PLLC

(2)

Hubbard

ip

Agenda

• Java API and Android API and issues involved in Oracle v. Google

• Basic copyright issues

• Rationale of decision by court on issue of copyrightability of Java API

• Legal and business ramifications

• Other modes of protection

• Eﬀect on protecting APIs as well as class names, file formats, protocols and other types of specifications

• Business ramifications for the computer industry, open source initiatives,and the adoption of standards.

(3)

Hubbard

ip

Lawsuit

• Early 2010: Oracle acquired Sun Microsystem and Sun’s interest in Java

• Late 2010: Oracle sued Google, accusing Google’s Android operating system of —

• Infringing copyright in Java API

• Patent infringement

• Trial in two phases in 2012:

• Copyright — Java API presumed to be copyrightable; jury found infringement and no fair use

• Patent - Jury found no infringement

• Court issued order after trial, on May 31, finding that Java API not copyrightable

• Oracle has filed notice of appeal

(4)

Hubbard

ip

What is “Java”?

• It’s an object-oriented programming language based on C and C++ that can be used to write source code for compiling into a platform independent object code called “bytecode”

• It’s a software “platform” that allows creation of applications that for “write once, run anywhere”

• A “virtual machine” (one for each OS/hardware platform) (“JVM”)

• Interprets (executes) applications written in Java

• Provides the abstraction layer necessary to achieve platform independence for applications

• An extensible application programming interface (API)

• Comprised of multiple libraries, referred to as “packages,” of previously written software (classes and

interfaces) that provide “core” functions that can be called by applications in written Java and running on a Java virtual machine

• Very helpful to application programmers; some are arguably necessary for many functions because of hardware-dependency of the implementation

(5)

Hubbard

ip

5

(6)

Hubbard

ip

Object oriented programming Java style

• A function that can be called by an application is referred to as a “method”

• Each method must be a member of a “class”

• Every Java program must have one class with one method

• A class may implement more than one method

• Classes may be grouped into “packages”

(7)

Hubbard

ip

Java API classes written using Java

7

package java.lang; public class Math {

public static int max (int x, int y) { if (x > y) return x ;

else return y ; }

}

Declares package “java.lang” Declares class “java.lang.math”

Declares method “java.lang.math.max”

int a = java.lang.Math.max (2, 3);

Body of method

Simplified example of package, class, method within API

Part of body of method in class file of an application calling method

Calling method “max” with arguments “2” and “3”

(8)

Hubbard

ip

Java class file example

8

public class Bicycle {

// the Bicycle class has // three fields

public int cadence; public int gear; public int speed;

// the Bicycle class has // one constructor

public Bicycle(int startCadence, int startSpeed, int startGear) { gear = startGear; cadence = startCadence; speed = startSpeed; }

// the Bicycle class has // four methods

public void setCadence(int newValue) { cadence = newValue;

}

public void setGear(int newValue) { gear = newValue;

}

public void applyBrake(int decrement) { speed -= decrement;

}

public void speedUp(int increment) { speed += increment;

} }

Declaration of the class and start of body of class

Declaration of method Body of Method

Declaration of data fields and their types for the class

(9)

Hubbard

ip

Java API

9

• In 1996, at the time Java was introduced, API had 8 packages

• 3 packages were “core,” meaning must have these three to be able to write

applications using Java (java.lang, java.io, java.util)

• Sun and Java Community Process developed standard specifications for Java

classes and methods and added many more packages, classes and methods

• By 2008, API had 166 packages, containing over 600 classes with over 6000

methods

(10)

Hubbard

ip

What is “Android”?

• A complete software stack for mobile devices that is open source and without

license fees

• Application programs are written in Java

• Allows large number of programmers already familiar with writing in Java to also

write for Android

• Android includes a virtual machine that is used to to interpret Java bytecode (.class or .jar file) that has been modified (into a “.dex” file) to run on a virtual machine that is part of OS called the Dalvick virtual machine

• Android Includes a library written in Java that implements 37 of Java’s 166 packages

(11)

Hubbard

ip

Android System Architecture

11

Google’s version of the Java virtual machine specially tuned for mobile environment API of core packages Blue = written in Java

(12)

Hubbard

ip

Points of similarity between 37 packages

implementing Android API and Java API

12

• Functions that are available, including inputs and outputs

• Names of packages, classes, methods, and arguments generally identical (for convenience of application developers)

• Arrangement of the methods into classes, and the arrangement of classes into packages

• Declaration statements for packages, classes and methods

• Formats for declarations, etc., dictated by Java programming language

• “Throw” statements largely similar

• Standard terms dictated by Java programming language (e.g. “public,” “private,” “static”) and the types of values (e.g. “int”, “boolean,” “char,” and “string”)

(13)

Hubbard

ip

Points of dissimilarity

• Instructions that implement the method — the body of the methods

• NET RESULT

• 3% of the lines in the 37 packages of the Android API are identical to Java API

• 97% of the lines are dissimilar

(14)

Hubbard

ip

Business background

• Sun sued Microsoft in 1997 for breach of a licensing agreement because of incompatible version of Java VM that allowed developers to take advantage of Windows features.

• Microsoft referred to its version of the VM as “Java”, which seemed to be the primary point of contention

• Sun wanted Google to pay a big license fee to call its phone a Java phone, and join Nokia, Motorola, Blackberry (RIM) and others in developing apps that run across all the platforms.

• Java licensing was a $100 million plus business for Sun

• Sun would also profit by enlarging the Java community and creating more of a barrier to competition with Microsoft, et al.

(15)

Hubbard

ip

Google’s position

• As long as it is not referring using the “Java” trademark, or implying that it’s platform was “Java” or fully compliant with the Java specifications, it was free to build a VM that could run programs written in Java unless there was a patent.

(16)

Hubbard

ip

Oracle’s purported concern

16

• “Fragmentation” / Balkanization of platforms

• Imperfect interoperability among platforms means that Java applications will not run on incompatible platforms.

• Java applications relying on unsupported packages will not run on Android

• Licensing requirements avoid fragmentation problems

• Questions: if fragmentation was really the issue, would Oracle have sued Google if it has implemented all 166 of the Java API packages?

• There were any number of ways to organize functions of the API into classes, the classes into packages, and to name the various classes and packages, and there was a signficant amount of expression involved in the particular API.

(17)

Hubbard

ip

Fairness issue

• Is it fair to allow Google to gain the benefit of the Java ecosystem without paying for the privilege of using it, or at least contributing to it?

• Subject to patent rights, Google or anyone else to could have created a virtual

machine and an API oﬀering the same set of functionality, but with diﬀerent names for the packages, classes and methods

• Google obviously wanted the advantages of Java without abide by the restrictions

imposed by Sun or Oracle

(18)

Hubbard

ip

Fundamental legal principles guiding decisions as

formulated by district court

18

• There is no decision directly on point; no court has ever decided the issue of whether a computer API was protectable by copyright.

• Under 17 U.S.C. §102(b), copyright protection never extends to any idea, procedure, process, system, method of operation or concepts regardless of the form. (The idea/expression dichotomy)

• Functional elements essential for interoperability are not copyrightable.

• Under the merger doctrine, when there is only one or just a few ways to express something, no one can claim ownership of such expression by copyright.

• Under the names doctrine, names and short phrases are not copyrightable.

• Court should not yield to temptation to find copyrightability merely to reward an investment in a body of intellectual property.

• “Sweat of the brow” doctrine rejected in U.S. Supreme Court in Feist Publications, Inc., v. Rural Telephone Service Co., 499 U.S. 340 (1991).

(19)

Hubbard

ip

Origin of idea / expression dichotomy and merger

doctrine

• Baker v. Seldon, 101 U.S. 99 (1879)

•Book on new system of double-entry accounting, which included blank form;

infringer made use of method of bookkeeping, but used diﬀerent forms.

•And where the art it teaches cannot be used without employing the methods and

diagrams used to illustrate the book, or such as are similar to them, such

methods and diagrams are to be considered as necessary incidents to the art, and given therewith to the public; not given for the purpose of publication in other

works explanatory of the art, but for the purpose of practical application.

(20)

Hubbard

ip

20

Idea / expression dichotomy as codified in 1976

Copyright Act

However, the Copyright Act does not contain explicit standards for separating ideas from expression.

(21)

Hubbard

ip

Merger doctrine rationale

21

• Where idea and expression are intertwined and where non-protectable ideas

predominate, copyright protection does not exist because granting protection to the expressive component necessarily would extend protection to the work’s

uncopyrightable ideas as well.

• The merger doctrine is applied as a prophylactic device to ensure that courts do not

unwittingly grant protection to an idea by granting exclusive rights to the only, or one of only a few, means of expressing that idea.

• See Gates Rubber Co. v. Bando Chemical Indus., Ltd., 9 F.3d 823 (10th Cir. 1993); Lexmark Int’l, Inc. v. Static Control Components, Inc., 387 F.3d 522 (6th Cir. 2004); ;

Murray Hill Publ’ns, Inc. v. Twentieth Century Fox Film Corp., 361 F.3d 312 (6th Cir. 2004); Concrete Machinery Co. v. Classic Lawn Ornaments, Inc., 843 F.2d 600, 606-607 (1st Cir. 1988); Apple Computer, Inc. v. Microsoft Corp., 799 F.Supp. 1006 (N.D.Cal. 1992).

(22)

Hubbard

ip

Names and short phrases not protectable

22

§ 202.1

Material not subject to copyright.

The following are examples of works not subject to copyright and applications for registration of such works cannot be entertained:

(a) Words and short phrases such as names, titles, and slogans; familiar

symbols or designs; mere variations of typographic ornamentation, lettering or coloring; mere listing of ingredients or contents;

Rule followed in 9th Circuit. Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992), (a competitor’s use of Sega’s initialization code, consisting of

merely of 20 bytes of initialization code plus the letters S-E-G-A, was of de minimis length and therefore likely a “word” or “short phrase” that is not protected)

Copyright Oﬃce regulation 37 C.F.R. 202.1(a)

Most other circuits appear to have accepted this regulation as a fair statement of the law

(23)

Hubbard

ip

Disfavor of “structure, sequence and organization”

theory

• Court acknowledged that non-literal elements of computer software — “structure, sequence and organization” — can by protected by copyright

• Whelan Associates, Inc. v. Jaslow Dental Laboratory, Inc., 797 F.2d 1222 (3d Cir. 1986) (structure

of program for managing a dental oﬃce was copyrightable because there were many diﬀerent ways to structure a program to manage a dental laboratory)

• Johnson Controls, Inc. v. Phoenix Control Sys., Inc., 886 F.2d 1173, 1175 (9th Cir. 1989)(aﬃrming

under abuse of discretion standard finding that SSO of program was protectable expression on grounds that there was evidence that there was room for creativity in expression of functions.)

• But court noted that SSO type of analysis had become disfavored in 9th circuit and other circuits, had been heavily criticized, and failed to recognize the danger of conferring monopoly by copyright over Congress had expressly warned should only be granted by patent. See Sega Enters., Ltd. v.

Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992)

• Whelan and Johnson Controls: “Too narrow a view of the ‘idea’”

(24)

Hubbard

ip

Court favors abstraction, filtration and comparison

analysis

24

• Originally developed in the Computer Assocs. Int’l, Inc. v. Altai, Inc., 982 F.2d 693 (2nd Cir. 1992) as an aid to analyze to distinguish between unprotectable ideas and protectable expression when comparing software programs for substantially

similarity.

• (1) Dissect program according to its varying levels of generality to provide a framework

• (2) Examine each level of generality or abstraction in order to filter out those elements of the program which are unprotectable.

• (3) Compare of the remaining protectable elements with the allegedly infringing work to determine whether the defendants have misappropriated substantial elements of the plaintiﬀ’s work.

(25)

Hubbard

ip

Filtration of unprotectable elements

• (1) Structure based on “practical considerations”

• (2) Structures dictated by external factors

• “standard techniques”

• Extrinsic considerations such a computer hardware, compatibility requirements with other programs, demands of industry being serviced, widely accepted programming practices, hardware standards, software standards, mechanical specifications

• Scènes à faire doctrine

• (3) Structures already found in public domain

(26)

Hubbard

ip

Court concerned that SSO is domain of patents

26 United States District Court Fo r th e No rth ern District of Califo rn ia 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 15

• Catchwords, catchphrases, mottoes, slogans, or short advertising expressions.

• Listings of ingredients, as in recipes, labels, or formulas. When a recipe or formula is accompanied by an

explanation or directions, the text directions may be copyrightable, but the recipe or formula itself remains uncopyrightable.

U.S. Copyright Office, Circular 34; see 37 C.F.R. 202.1(a).

This rule is followed in the Ninth Circuit. Sega Enters., Ltd. v. Accolade, Inc., 977 F.2d 1510, 1524 n.7 (9th Cir. 1992). This has relevance to Oracle’s claim of copyright ownership over names of methods, classes and packages.

2. THE DEVELOPMENT OF LAW ON THE COPYRIGHTABILITY

OF COMPUTER PROGRAMS AND THEIR STRUCTURE,

SEQUENCE AND ORGANIZATION.

Turning now to the more difficult question, this trial showcases a distinction between copyright protection and patent protection. It is an important distinction, for copyright

exclusivity lasts 95 years whereas patent exclusivity lasts twenty years. And, the Patent and Trademark Office examines applications for anticipation and obviousness before allowance whereas the Copyright Office does not. This distinction looms large where, as here, the vast majority of the code was not copied and the copyright owner must resort to alleging that the accused stole the “structure, sequence and organization” of the work. This phrase — structure, sequence and organization — does not appear in the Act or its legislative history. It is a phrase that crept into use to describe a residual property right where literal copying was absent.

A question then arises whether the copyright holder is more appropriately asserting an exclusive right to a functional system, process, or method of operation that belongs in the realm of patents, not copyrights.

A. Baker v. Seldon.

The general question predates computers. In the Supreme Court’s decision in Baker v. Seldon, 101 U.S. 99 (1879), the work at issue was a book on a new system of double-entry bookkeeping. It included blank forms, consisting of ruled lines, and headings, illustrating the

(27)

Hubbard

ip

Holding 1

: Specification for each method is an idea

27

• “The method specification was the idea. The method implementation is the expression.”

• Google used its own code to implement method specification, including inputs, outputs, etc.

• Names of individual methods, classes and packages not protectable

• The declarations, save for the argument names, dictated by rules of Java (external considerations and interoperability)

• As long as the specific code written to implement a method is diﬀerent, anyone

is free under the Copyright Act to write his or her own method to carry out exactly the same function or specification of any and all methods used in the Java API. Ideas, functions and concepts cannot be “monopolized” by copyright.

(28)

Hubbard

ip

Holding 2

: overall system of organization of methods

not protectable

• Arrangement of methods into classes, and classes into packages involved creativity

and resembles a taxonomy, but it is nevertheless a command structure or system or method of operation.

• Because the use of the same taxonomy or command structure was necessary to

achieve interoperability, it has to be a method of operation

• Google replicated what was necessary, but not more than necessary, to achieve

interoperability.

• Oracle’s fears of fragmentation and imperfect interoperability arising from incomplete implementation of API tends to confirm that it is a method of operation

(29)

Hubbard

ip

Implications

• It is the first decision to address squarely issue of protectability of specification of computer API

• Will have to see how the appellate court reacts.

• This is not a holding that all APIs cannot be protected by copyright. However, it is diﬃcult to imagine when an API would be copyrightable. If copying of elements necessary to achieve interoperability or compatability will always be permitted, APIs will not likely ever be found to be protectable by copyright.

• If decision is upheld on appeal, the only real legal limits on third parties recreating a software or hardware “platform” will be:

• Contractual limitations

• Patents

• Secrecy

• Trademarks

(30)

Hubbard

ip

Oracle/Sun failed at protecting Java API with patents

• Infringement of 7 patents plead

• Infringement claims with respect to 2 survived until trial and jury found no infringement

• Patents had little, if anything, to do with the Java API or its implementation

• Not so easy to obtain patents on method of operation of an API or to make a claim

of infringement stick

(31)

Hubbard

ip

Feasibility of protecting API with patents

• API software specifications, as such, are abstract

• Patent must claim a process, a machine or article of manufacture

• Must look to patent processes essential to implementation of the API

• However, patent eligibility of computer implemented processes under scrutiny

(32)

Hubbard

ip

Patents on software implemented inventions

• Bilski v. Kappos, 130 S.Ct. 3218 (2010)

• Laws of nature, physical phenomena, and abstract ideas are not patentable

• CLS Bank v. Alice Corp. en banc rehearing ordered by the Federal Circuit (involves computer implemented financial business method):

• “What test should the court adopt to determine whether a computer-implemented invention is a patent ineligible "abstract idea"; and when, if ever, does the presence of a computer in a claim lend patent eligibility to an otherwise patent-ineligible idea?

• “In assessing patent eligibility under 35 U.S.C. § 101 of a computer-implemented invention, should it matter whether the invention is claimed as a method, system, or storage medium; and should such claims at times be considered equivalent for § 101 purposes?”

(33)

Hubbard

ip

33

Invention / Practical application of idea Abstract idea Expression of idea

The abstraction chasm

§101 case law pushing fuzzy boundary one direction

Case law relating to

copyrightability of program structures pushing fuzzy boundary the other direction Method of operation, process, system

(34)

Hubbard

ip

Basic advice to clients developing an API or hardware

or software “platform”

• Keep secret; avoid “open source” or “open standard;” self-help precautions

• Aggressive contractual and licensing provisions to keep API and other interfaces

secret

• Patent all novel processes essential to implementing or supporting API specification

• If business model depends on “open” API or open standard, there may not much

that can be done, other than create circumstances which favor inclusion rather than exclusion

(35)

Hubbard

ip

Basic advice to client wanting to develop

interoperable software and hardware

• Avoid contracts with party who developed platform (watch for implied contracts

associated with using specification)

• Evaluate patents

• Avoid confidentiality restrictions

• Avoid using trademarks

• Reverse engineer using clean room techniques that are consistent with current law

• Otherwise, have at it

(36)

Hubbard

ip

Open source and standards

• Generally viewed by the popular media and software programmers as good for open source; one less obstacle

• However, strong copyright protection is, arguably, essential to

• Enforcing licensing requirements in open source (e.g. contribution of derivatives, limits on commercial uses, etc)

• Less ability to control development and guard against splintering or forking in standards

• More diﬃculty in getting standards oﬀ the ground

• One less means to force cooperation among all of the players, and to encourage others to join

(37)

Hubbard

ip

Conclusions

• Court’s decision expresses a consistent theme found in cases, which is the concern

over the extrinsic eﬀects of extending copyright protection

• Specifications for an API, file format, etc. generally exist to achieve interoperability. If reasoning of this decision is followed, APIs are likely not to be protectable under

copyright under rationale that they are methods of operation.

• Similarities in expression occurring within an implementation essential to

implementation of a specification are likely not protectable under the merger or

scènes à faire doctrines.

• Subject to misappropriation of trade secrets, contractual limitations, patents, and trademark rights, software and hardware platforms appear to be generally free for the taking

(38)

Marc A. Hubbard

Hubbard Law PLLC