The API copyright question is back in the news these days. By declining to hear the high-profile Oracle v. Google case, the Supreme Court recently upheld a lower-court ruling that the Java API is protected by copyright. What does this mean for developers and IT and business leaders? What do they need to do now when they build or use APIs? Listen to the podcast version here: http://bit.ly/1gmI13y Watch the full recording here: http://youtu.be/Awppowtt4EM

1. API Copyrights: New Considerations for
Building or Using APIs
Stacey Giamalis
Ed Anuff

2. Presenters
2
Stacey Giamalis
Apigee Legal Function Lead
Ed Anuff
Apigee Product Strategist and
Developer

3. Context
• Intended for API users and API creators who are curious about the impact of this
decision on them
• Not a critical analysis
• Not legal advice
• Oracle v. Google background
– 2010: patent and copyright claims on Java API (not the implementing code)
– 2012: federal trial court says Java API not copyrightable (ie not protected by copyright)
– 2014: federal appeals court decides that Java API declaration headers and overall structure,
sequence, and organization protected by copyright
– June 2015: Supreme Court decides not to review federal appeals court decision
• Copyright infringement requires three elements, only two of which were before the
court
– a work protected by copyright
– infringement of the copyright by copying, distributing, etc.
– no valid defense to infringement, such as fair use
3

4. The case: issues decided by the federal circuit
• Was the trial court correct in holding that the Java API declaration headers were
not protected by copyright due to merger and method of operation?
– the federal Circuit said “No”
• Did Google’s use of the Java API constitute fair use?
– the federal circuit court said: “Not enough facts for us to decide; trial court needs to
rehear this part”
4

5. The case: facts
• The Java API is complex and intricately organized
– an API is an architecture for making operations and resources of a program available for use
by another program, along with instructions on how to write code to access those
operations and resources
– the Java API is 6,000 methods (or routines), which are combined with variables and other
items and grouped into subclasses, which are grouped into 600 classes, and the 600
classes are combined with interfaces and grouped into 166 API packages
• Google admitted that it copied the exact declaration headers for 37 of the Java
API packages and the exact structure, order, and organization of their routines
– Declaration header example: public static int max (int x, int y)
5

6. The case: facts (cont’d)
• The Java API packages that Google incorporated into the Android API did not
allow the Android platform or Android OS apps to access, or interoperate with,
the Java platform
• Java API licensing conversations between Sun and Google broke down over
Google’s refusal to follow Java’s core standard of “write once, run anywhere”
– AndroidOS apps do not run on other Java-based platforms
6

7. The case: federal circuit’s holdings
• Java API declaration headers are copyrightable
– “idea/expression merger” (only one, or only a few, ways to write something)
• federal circuit held that in the Ninth Circuit, idea/expression merger is for defense against
infringement, not relevant for copyright
• however, court said merger not present here with possible exception
– names and short phrases
• by regulation, words and short phrases comprising names are not copyrightable
• but compilations of non-protected items are protectable under copyright law if there was
creativity in the selection and arrangement of the items
• Structure, sequence and organization of the Java API is copyrightable
– the Java API is a creative and original taxonomy as determined by the trial court
• Google could employ a routine/class/package structure to offer the same functionality in
AndroidOS, but it cannot replicate the exact detailed arrangement of the Java routines
7

8. The case: court’s commentary on fair use
• Under Ninth Circuit law an interoperability need is relevant to a fair use defense,
not to copyrightability
• But Google was NOT trying to make Android OS compatible with Java platform
• Instead, Google wanted to accelerate availability of Android OS apps by
leveraging the fact that developers were already trained and experienced in
using Java
8

9. The Case: court’s commentary on fair use (cont’d)
• There are four fair use factors and they’re applied on a case-by-case basis:
1. Purpose and character of the infringing use
2. The nature of the copyrighted work (including how informative/functional vs. how creative)
3. The amount and substantiality of portion of the copyrighted work used
4. The effect of the use upon the value of or market for the copyright holder’s work
• Of these, #4 is by far the most important per the court
– the court was clearly troubled by Google’s objectives in copying the Java API
• Regarding #2, the court said that if copying of a (utilitarian) software program is
needed to perform the program’s functions, that could mean the use is fair
9

10. Comments and context: the decision
• The appeals court did not say all APIs are copyrightable
• Java API considered as a separate work from the underlying Java platform
• The case was NOT about implementing code that is written to an API
10

11. Comments and context: situational aspects
• Google cloned the Java API to use as its own API for its own program, and
displaced the Java platform
– Google used the Java API for a different and replacing use than what Sun created it
for (to call back to the Java platform)
• Google violated Java’s core standard and philosophy
• Google wanted to leverage developers’ familiarity with the Java API to make
easy porting of pre-Android OS Java apps to Android OS
– leveraging the network effects of the Java API
11

12. Comments and context: practical aspects
• Structure: Java code API particularly intricate
– compare structure of web APIs
• Resource names
– individual names vs. compilation of all names
– REST API resource names style
• Case NOT about using an API to access operations/resources of the underlying
program
– API has been published for that purpose
• language in the federal court’s decision honoring this
• legal theories (implied license, implied promise) and community enforcement
• explicit licensing
12

13. Suggested practices
• Avoid cloning APIs
• Create your own APIs—degree of similarity to other APIs
– web APIs (RESTful or SOA APIs)
• Consulting well-known APIs
– resource names
• generate your own; different can be good
– structuring your API
– general structure vs. identical organization of all items to another API
– explicitly license your API
13

14. Situations
• Example: creating an API for a third-party program that doesn’t have one
• Example: creating connecting code for a third-party program (either without an
API, or ignoring/subverting the API)
• Example: creating mashups/super APIs
• Is another’s API or underlying program (may be separate works) being either
literally copied, or is its structure, sequence, or organization being copied?
• What is the purpose for which the API/connecting code is being created?
14

15. Conclusion
• Nothing has changed in terms of using APIs to access operations and
resources of an underlying program
• Biggest issue in API creation is in cloning vs. creating your own APIs
• Fair use decision in Oracle v. Google coming later
15

16. Thank you
Special thanks to Heather Meeker, partner at the O’Melveney firm,
for her contributions to this presentation