API Copyrights: New Considerations for Building or Using APIs
1 like5,102 views
The document discusses the implications of the Oracle v. Google case regarding the copyrightability of the Java API, particularly focusing on the court's decisions and commentary surrounding fair use. It clarifies that while the structure, sequence, and organization of the Java API are copyrightable, Google’s copying of certain aspects does not fully constitute fair use. The presentation concludes with suggested practices for API creation to avoid legal conflicts, emphasizing the importance of originality over cloning.
API Copyrights: New Considerations for Building or Using APIs
- 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