Google LLC v. Oracle America, Inc.

From Infogalactic: the planetary knowledge core
Jump to: navigation, search
Google LLC v. Oracle America, Inc.
Seal of the United States Supreme Court.svg
Argued October 7, 2020
Decided April 5, 2021
Full case name Google LLC v. Oracle America, Inc.
Docket nos. 18-956
Citations 593 U.S. ___ (more)
141 S. Ct. 1183
209 L. Ed. 2d 311
Argument Oral argument
Prior history
  • Oracle Am., Inc. v. Google Inc., 872 F. Supp. 2d 974 (N.D. Cal. 2012); reversed and remanded, 750 F.3d 3303 (Fed. Cir. 2014); cert. denied, 135 S. Ct. 2887 (2015)
  • Oracle Am., Inc. v. Google Inc., No. 3:10-cv-03561, 2016 WL 1647639 (Sept. 27, 2016); reversed, 886 F.3d 1179 (Fed. Cir. 2018); cert. granted, 140 S. Ct. 520 (2019)
Subsequent history On remand, Oracle Am., Inc. v. Google LLC, No. 2017-1118, 2021 WL 1941874 (Fed. Cir. May 14, 2021)
Questions presented
  • Whether copyright protection extends to a software interface.
  • Whether, as the jury found, petitioner's use of a software interface in the context of creating a new computer program constitutes fair use.
Court membership
Case opinions
Majority Breyer, joined by Roberts, Sotomayor, Kagan, Gorsuch, Kavanaugh
Dissent Thomas, joined by Alito
Barrett took no part in the consideration or decision of the case.

Google LLC v. Oracle America, Inc., 593 U.S. ___ (2021),[1] was a U.S. Supreme Court decision related to the nature of computer code and copyright law. The dispute centered on the use of parts of the Java programming language's application programming interfaces (APIs) and about 11,000 lines of source code, which are owned by Oracle (through subsidiary, Oracle America, Inc., originating from Sun Microsystems), within early versions of the Android operating system by Google. Google has since transitioned Android to a copyright-unburdened engine without the source code, and has admitted to using the APIs but claimed this was within fair use.

Oracle initiated the suit arguing that the APIs were copyrightable, seeking US$8.8 billion in damages from Google's sales and licensing of the earlier infringing versions of Android. While two District Court-level jury trials found in favor of Google, the Federal Circuit court reversed both decisions, asserting APIs are copyrightable and Google's use does not fall under fair use. Google successfully petitioned to the Supreme Court to hear the case in the 2019 term, focusing on the copyrightability of APIs and subsequent fair use; the case was delayed to the 2020 term due to the COVID-19 pandemic. In April 2021, the Supreme Court ruled in a 6–2 decision that Google's use of the Java APIs fell within the four factors of fair use, bypassing the question on the copyrightability of the APIs. The decision reversed the Federal Circuit ruling and remanded the case for further review.

The case has been of significant interest within the tech and software industries, as numerous computer programs and software libraries, particularly in open source, are developed by recreating the functionality of APIs from commercial or competing products to aid developers in interoperability between different systems or platforms.

Background

Java development

Java was originally developed at Sun Microsystems starting in December 1990.[2] It included a new programming language, a virtual machine, and a set of libraries for use with the language.[3] These libraries are documented for programmers via application programming interfaces (APIs), which tell programmers what information to provide to library functions and what results to expect back, eliminating any need for the programmer to know how the library they are using does what it does. These libraries together provide the "Java virtual machine" which programmers write programs to use (run upon). The common way in which a common set of libraries are used across all "Java virtual machines" allows for interoperability, or as marketed by Sun, "Write once, run anywhere"; a programmer need only create one version of their software which, because of the single group of APIs common to all Java virtual machines, can thus be run on any computing platform that supports Java.

The Java language was released to the public in 1995, under the Sun Community Source License, making the source code freely available but requiring that products using the code were maintained to the Java standard, and that any commercial derivative works were licensed by Sun.[4][5] While anyone could program in the language itself, Sun maintained the Java Platform, Standard Edition (Java SE) and Mobile Edition (Java ME) libraries, provided to users as pre-compiled Java bytecode, and their respective APIs, as well as the Technology Compatibility Kits (TCKs) that tested an implementation against the Java standard.[6] Over 2006 and 2007, due to pressure from developers, Sun changed the license of the various Java packages to use the GNU General Public License with a "classpath exception", allowing developers the access necessary to make derivative works and the ability to release applications under a different license. This led to the OpenJDK (Open Java Development Kit), first released in 2007. Sun retained strong control over the language and standards itself, licensing the necessary elements like TCKs for commercial users.[5] At this time, Sun's business model changed to focusing on licensing of the Java platform to embedded devices, particularly mobile phones, and had already made licensing deals with Nokia, Motorola, and Research In Motion.[7]

Android development

Android, Inc. was founded in 2003 by Andy Rubin, Rich Miner, Nick Sears, and Chris White to develop a mobile phone platform.[8][9] Google purchased Android in 2005 and continued developing the Android operating system.[9] During the development of Android, Google wanted to incorporate the Java SE libraries. Google's executive chairman Eric Schmidt had approached Sun's president Jonathan I. Schwartz about licensing the Java libraries for use in Android. Sun offered a licensing deal of between US$30 and 50 million. Schmidt said Google would have paid for that license, but they were concerned that Sun had also requested some shared control of Android along with the fee.[10][11][12] Google states that they wanted more control in order to open source the language and allow third parties to take better advantage of its code;[10] Oracle states that Sun refused because Google's intention was essentially to fork Java to a Google version of the language, and to prevent it being inter-operable with other versions, an idea which was "anathema" to the "write once run anywhere" basis of the language.[13] Because of these differences of view, the negotiations failed to reach a deal and Sun refused Google a license for Java.[13]

At this point in time, the OpenJDK implementation offered by Sun was not as mature or complete as the Java Standard Edition.[14] Instead of licensing Java, Google chose to develop a cleanroom version of the Java Standard Edition libraries, developing the libraries from a completely fresh start without any access to Sun's code. This became the engine behind Android's Dalvik virtual machine, a core part of the new system. Part of the virtual machine included 37 API calls and around 11,500 lines of code deemed central to Java, which were taken from Apache Harmony, an open-source cleanroom Java implementation developed by the Apache Software Foundation (ASF). Prior to this, the ASF had tried to obtain necessary licenses from Sun to support the Apache Harmony project as to call it an official Java implementation, but could not, in part due to incompatible licensing with Java's GNU General Public License and ASF's Apache License, nor could it gain access to the Java TCKs to validate the Harmony project against Sun's implementation.[15][16] Though Google stated they used this code to ensure interoperability with the Java Standard Edition for other programmers,[6] during the second appeal hearing, Google stated that it had used this code for commercial reasons to rapidly complete Android and to avoid the "drudgery" of recreating the code.[13] ASF ceased maintaining the Apache Harmony in 2011, leading Google to take over maintenance of these libraries.[14]

Google released a beta of the Android platform on November 5, 2007 then, one week later, the software development kit (SDK) which they noted included some Java technologies.[17][18][19] Sun's president Schwartz congratulated Google the same day, saying they had "strapped another set of rockets to the community's momentum – and to the vision defining opportunity across our (and other) planets."[20] During the trial, Schwartz said that at that time of Android's release, despite knowing Google may have bypassed their licensing requirements, "We decided to grit our teeth and support it so anyone supporting it would see us as part of the value chain".[7]

Oracle announced it would purchase Sun in April 2009 for US$7.4 billion, and completed the acquisition in January 2010.[21] Besides allowing them to enter the hardware business, Oracle's CEO Larry Ellison called the Java language "the single most important software asset we have ever acquired".[22] Oracle continued to develop Java and pursue licensing opportunities following its acquisition of Sun.

By the release of Android KitKat (v4.4) in 2013, Google removed the Dalvik virtual machine and replaced it with the Android Runtime, which had been built within Google without any of the Java source code.[23] However, Android continued to use the JavaSE APIs through the extent of the case's litigation up until Android Nougat when it was fully replaced by OpenJDK.[24][25]

First phase: API copyrightability and patents

The first phase of the case lasted from 2010 to 2015. Oracle successfully established that APIs are copyrightable, but their claims of patent infringement were rejected.

First District Court trial

Judge William Alsup, who presided over both trials at the District Court level

On August 13, 2010, Oracle sued Google for copyright and patent infringement in the District Court for the Northern District of California. Oracle asserted Google was aware that they had developed Android without a Java license and copied its APIs, and that Google therefore infringed Oracle's copyright. Oracle also cited seven prior patents related to the Java technology created by Sun and now owned by Oracle that Google should have been aware of as they had hired former Sun developers that worked on Java. Oracle sought both monetary damages and an injunction to stop Google from using the allegedly infringing materials.[26][27]

The case was assigned to Judge William Alsup, who split the case into three phases: copyright, patent, and damages.

The copyright phase started on April 16, 2012, and consisted of several distinct claims of infringement: a nine-line rangeCheck function, several test files, the structure, sequence and organization (SSO) of the Java (API), and the API documentation.

Oracle alleged infringement of 37 separate Java APIs which had derived from the Apache Harmony project.[11] After two weeks of testimony, the jury found on May 7, 2012, that Google had infringed on the copyright related to the code, SSO, and documentation of the APIs as well as the rangeCheck function, but were deadlocked on whether these uses fell within fair use. The jury also found that Google had sufficient reason to believe based on Sun's and Oracle's conduct that they did not need to license Java from Sun or Oracle, but did not rely on this when developing Android.[28] Oracle requested a judgement as a matter of law (JMOL) that the case dismiss any fair use defense since the jury was split, as well as to overturn the jury's decision on eight security-related files that they had reviewed and found non-infringing but which Google had stated they copied verbatim; Alsup concurred. Google asked for a similar JMOL related to rangeCheck, but Alsup denied this request.[29]

The patent phase began on May 7, 2012, with the same jury.[30] By the time of trial, Oracle's patent case comprised claims from two patents, 6,061,520 (Method and system for performing static initialization),[31] (the '520 patent) and RE38104 (Method and apparatus for resolving data references in generated code).[32] (the '104 patent). Google pursued a non-infringement defense. For the '520 patent, they argued that they were using parsing for optimizing static initialization, rather than "simulating execution" as the claim required. For the '104 patent, they argued that the instruction did not include a symbolic reference. On May 23, 2012, the jury found non-infringement on all patent claims.[33][34][35]

Judge Alsup issued the final verdict for both these phases on May 31, 2012. While the jury had found for Oracle regarding copyright infringement of the APIs, Alsup determined that the APIs were not copyrightable in the first place:

<templatestyles src="Template:Blockquote/styles.css" />

So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical.[11]

Alsup did agree with the jury that the rangeCheck function and eight security files were a copyright infringement, but the only relief available was statutory damages up to a maximum of US$150,000[36][37]

As a result of these rulings and a stipulation, there was no jury damages phase. The parties agreed to zero dollars in statutory damages for the small amount of copied code by June 2012.[38][39]

First appellate ruling

Shortly following the conclusion of the District Court case, both parties attempted to file additional JMOLs on elements of the ruling which Alsup dismissed, leading to Oracle appealing the decision and Google filing a cross-appeal on the literal copying claim. Because the case involved claims related to patents, the appeal was automatically assigned to the United States Court of Appeals for the Federal Circuit.[40][41] The hearing was held on December 4, 2013,[42][43] and the judgment was released on May 9, 2014.[44]

The court noted that Copyright Act provides protection to "original works of authorship fixed in any tangible medium of expression" (p. 17). The legislative history explains that literary works include "computer programs to the extent that they incorporate authorship in the programmer's expression of original ideas, as distinguished from the ideas themselves" (p. 18). To qualify for copyright protection a work must be original. 17 U.S.C. § 102(a). The court was therefore "first to assess whether the expression is original to the programmer" (p. 24), something that Google had already conceded (p. 21). This led the court to conclude "that the overall structure of Oracle's API packages is creative, original, and resembles a taxonomy" (p. 14). It therefore reversed the district court's decision on the central issue, holding that the "structure, sequence and organization" of an API is copyrightable. It also ruled for Oracle regarding the small amount of literal copying, holding that it was not de minimis. The case was remanded to the District Court for a second trial, to consider whether Google's use was acceptable anyway, under the doctrine of fair use, since the original case had not brought out the facts related to fair use sufficiently for the Appeal Court to rule on that point.[44][45]

In October 2014, Google petitioned the U.S. Supreme Court to hear the case;[46] this request was denied in June 2015.[47]

Second phase: fair use

Second District Court trial

As ordered by the Appeals Court, a new district court trial began on May 9, 2016, on the question of whether Google's actions were fair use given the prior ruling that the APIs were copyrightable.[48][49] Closing arguments were completed on May 23, 2016 and the jury began deliberations. Oracle was seeking damages of up to US$9 billion.[50][51][52][53][54][55] On May 26, 2016, the jury found that Android did not infringe Oracle-owned copyrights because its re-implementation of 37 Java APIs was protected by fair use.[56] Oracle announced its intention to appeal,[57] but before doing so, it attempted unsuccessful motions to disregard the jury verdict,[58] and then to hold a re-trial.[59][60] Oracle officially filed its appeal on October 26, 2016.[61]

Second appellate ruling

Oracle's appeal was heard by the United States Court of Appeals for the Federal Circuit in 2017. On March 27, 2018, the Court ruled in favor of Oracle.[62] The ruling analyzed the aspects of a "fair use" claim which were to be decided by a judge and jury, respectively. It then looked at the factual matters which, it had to be assumed, the jury had reached, and their implications in law.[62] It noted that in a "mixed" case of fact and law, such as the present dispute, the trial jury's role is to decide on the facts. Judge Alsup quoted the Supreme Court case Campbell v. Acuff-Rose Music, Inc. 510 U.S. 569 (1994) in his opinion, noting that:

<templatestyles src="Template:Blockquote/styles.css" />

truth, in literature, in science and in art, there are, and can be, few, if any, things, which in an abstract sense, are strictly new and original throughout. Every book in literature, science and art, borrows, and must necessarily borrow, and use much which was well known and used before[62]

The Appeal Court's role is to assess whether a reasonable jury could have reached the conclusions it did, and whether the judge's decision could be correct and reasonable in law. The standard review of mixed questions of law and fact concerned three components: "(1) determining the legal standard governing the question posed and what types of historical facts are relevant to that standard; (2) finding what the historical facts in the case at hand are; and (3) assessing whether the historical facts found satisfy the legal test governing the question to be answered" (Decision p. 19). Except clear error, the role of the jury is limited to determining disputed 'historical facts' (2). The facts are not discussed. "It is undisputed that Google copied verbatim the declaring code of the 37 Java API packages 11,500 lines of Oracle’s copyrighted code. It also copied the SSO of the Java API packages. (Decision p. 10)" It is also established and Google recognizes that the software copied is creative and original.

The Court found that as a matter of law, Google's use of Java could not have fallen within fair use, even if all factual matters decided by the jury had been in Google's favor. The Appeals Court found that Google's use of API code declarations had not met any of the four current criteria for fair use, but was merely untransformed reuse. It had not been transformative, since it was used for the same purposes without even minimal changes or rewrites. It was not minimal, since it was agreed that only 170 lines of the 11,500 lines copied were needed for Google's purposes. It was not within any example of transformation, nor intended to permit third party interoperability, since Google had made no substantial efforts to use them for the purpose of third party interoperability. (In fact it found that Google had tried to prevent interoperability with other Java and had previously been refused a license by Sun for that reason.[13]) It was not transformative in the sense of a new platform either, since other Java smartphones predated Android.[62] It was plausible that the use had harmed Sun/Oracle – perhaps to a great extent if Oracle were to be believed – since as a result, vendors began expecting Oracle to compete on price with a freely available derivative of its own language, and to require very steep discounts and undesired contractual terms.[62] Therefore, Google's use of the Java code and APIs failed to meet all four of the currently accepted criteria under which fair use would be possible.[62]

Instead, the Court found that Google's purpose had been to enhance its nascent Android platform's attractiveness to existing developers, who were often familiar with Java, and to avoid the "drudgery" of rewriting the code (which they could have done) needed to implement the 170 lines of API detail which were indeed required. "Making it easy for oneself", the court noted, is well established to not fall within valid grounds for fair use. The Court found that "The fact that Android is free of charge does not make Google's use of the Java API packages noncommercial".[63] Oracle

<templatestyles src="Template:Blockquote/styles.css" />

devised a licensing scheme to attract programmers while simultaneously commercializing the platform. In relevant part, Oracle charges a licensing fee to those who want to use the APIs in a competing platform or embed them in an electronic device. To preserve the "write once, run anywhere" philosophy, Oracle imposes strict compatibility requirements on licensees.[64]

The purpose was commercial, the established historical facts by the jury did not satisfy any of the criteria for fair use,[62] and the Court remanded the case back to the District Court of the Northern District of California to determine the amount of damage that Google should pay Oracle.[63]

Supreme Court

Google filed a petition for writ of certiorari with the Supreme Court of the United States in January 2019 to challenge the two rulings that were made by the appeals court in Oracle's favor. In its petition, Google centered its case on whether copyright extends to a software interface like an API, and whether the use of the Java API by Google fell within fair use as found at the jury trials.[65] In orders issued in April 2019, the Court asked the Solicitor General of the United States to file an amicus brief to outline the government's stance on the case.[66] The Trump administration backed Oracle and urged the Court to deny certiorari. Microsoft, Mozilla Corporation, Red Hat Inc., and others filed amicus briefs in support of Google's position.[67] IBM, the Computer & Communications Industry Association, the Internet Association, the Auto Care Association, and a collective group of over 150 academics and computer professionals also filed briefs supporting Google's stance, cautioning that a decision in favor of Oracle would hurt the computing world as a whole.[68]

The Supreme Court granted certiorari on November 15, 2019, and was expected to hear the case on March 24, 2020.[69][70][71] However, the Supreme Court postponed its March argument session on March 16 in light of concerns surrounding COVID-19, and later announced that Google v. Oracle was one of several cases from the 2019–20 term to be postponed until the first week of the 2020–21 term.[72][73][74] Following the delay, the Court asked parties to submit additional briefs related to Seventh Amendment question raised by Google, given that the Federal District court had overridden some of the findings of facts that the jury had concluded in their case at the District level.[75]

Oral arguments were heard via teleconference due to the ongoing COVID-19 pandemic on October 7, 2020.[76] Justice Ruth Bader Ginsburg had died the prior month, and her replacement, Justice Amy Coney Barrett, had not yet been confirmed, so Barrett took no part in the proceedings.[77] Court observers found that while the Justices seemed to side with Oracle on the copyright arguments, they also took deference to the arguments presented by Microsoft, who had taken Google's side on the case. Microsoft argued in an amicus brief that ruling in Oracle's favor could upend the software industry. Several questions focused on how APIs fell within the idea–expression distinction of copyright and if the merger doctrine would apply. Justice Gorsuch was also seen to focus heavily on the Seventh Amendment arguments and whether the Federal Circuit's ruling to overturn the trial court's jury verdict was proper.[76][78]

Decision

The Court issued its decision on April 5, 2021. In a 6–2 majority, the Court ruled that Google's use of the Java APIs was within the bounds of fair use, reversing the Federal Circuit Appeals Court ruling and remanding the case for further hearing. Justice Stephen Breyer wrote the majority opinion. Breyer's opinion began with the assumption that the APIs may be copyrightable, and thus proceeded with a review of the four factors that contributed to fair use:[79][80]

  1. The nature of the copyrighted work: Breyer's analysis identified that APIs served as declaring code rather than implementation, and that in context of copyright, it served an "organization function" similar to the Dewey Decimal System, in which fair use is more applicable.[81]
  2. The purpose and character of the use: Breyer stated that Google took and transformed the Java APIs "to expand the use and usefulness of Android-based smartphones" which "creat[ed] a new platform that could be readily used by programmers".[80] Breyer also wrote that Google limited to using the Java APIs "as needed to include tasks that would be useful in smartphone programs".[80]
  3. The amount and substantiality of the copyrighted material: Breyer said that Google only used about 0.4% of the total Java source code and was minimal. On the question of substantiality, Breyer wrote that Google did not copy the code that was at the heart of how Java was implemented, and that "Google copied those lines not because of their creativity, their beauty, or even (in a sense) because of their purpose. It copied them because programmers had already learned to work with [Java SE], and it would have been difficult … to attract programmers to … Android … without them."[80]
  4. The market effect of the copyright-taking. Breyer said that at the time that Google copied the Java APIs, it was not clear if Android would become successful, and should not be considered as a replacement for Java but as a product operating on a different platform.[80] Breyer further stated that if they had found for Oracle, it "would risk harm to the public", as "Oracle alone would hold the key. The result could well prove highly profitable to Oracle (or other firms holding a copyright in computer interfaces) ... [but] the lock would interfere with, not further, copyright's basic creativity objectives."[79]

Breyer determined that Google's use of the APIs had met all four factors, and that Google used "only what was needed to allow users to put their accrued talents to work in a new and transformative program".[79] Breyer concluded that "we hold that the copying here at issue nonetheless constituted a fair use. Hence, Google's copying did not violate the copyright law."[77] This conclusion rendered the need to evaluate the copyright of the API unnecessary.[79]

Justice Clarence Thomas wrote a dissenting opinion that was joined by Justice Samuel Alito.[82] Thomas wrote that the majority opinion created a new distinction between implementing code and declaring code that Congress had rejected, and thus, "the result of this distorting analysis is an opinion that makes it difficult to imagine any circumstance in which declaring code will remain protected by copyright."[24] Thomas further stated that in his own fair use analysis that "Google's use of that copyrighted code was anything but fair".[83]

Impact

Google v. Oracle was a closely watched case by the tech industry. A ruling favoring Oracle could have had significant effects on past and future software development given the prolific use of APIs.[84] Opponents of the Federal Circuit's ruling, including Google and other developers of Android-based software, had raised several concerns including the impact on interoperability, software innovation, and the potential for bad actors to pick up the rights to old software and file claims against companies who built their software on what were assumed to be open standards. If APIs became subject to copyright protection, it is believed that companies would need to implement deliberately incompatible standards to protect themselves from the risk of complex litigation. This scenario would mean moving away from the current trends in software development which have focused on improving interoperability between different services, allowing apps to communicate with one another, and creating more integrated platforms for end users.[65][14]

Industry and legal experts stated an Oracle victory could have created a chilling effect in software development, with copyright holders using the copyright on APIs to prevent their use in developing interoperable alternatives through reverse engineering, as common in open source software development.[85][86][87] At the same time, experts cautioned that a judgment favoring Google's position may weaken protection for copyright for software code developers, allowing competitors with better resources to develop improved products from smaller firms and reduce the motive for innovation within the industry.[88][89]

One example identified by Wired is the Linux operating system. While Linux is fully open source, it is based on POSIX, a set of APIs that mimic those of the commercial Unix operating system that enable high levels of interoperability for developers; a programmer would only need to write one set of code which then can be compiled on any system that has the same API, even if the computing architecture of the systems are different. If case law favored Oracle, the current owners of Unix, Micro Focus, could have sought damages from any POSIX-based operating system developer intending to use the operating system for commercial use.[90]

See also

References

  1. Google LLC v. Oracle America, Inc.
  2. Lua error in package.lua at line 80: module 'strict' not found.
  3. Lua error in package.lua at line 80: module 'strict' not found.
  4. Lua error in package.lua at line 80: module 'strict' not found.
  5. 5.0 5.1 Lua error in package.lua at line 80: module 'strict' not found.
  6. 6.0 6.1 Lua error in package.lua at line 80: module 'strict' not found.
  7. 7.0 7.1 Lua error in package.lua at line 80: module 'strict' not found.
  8. Lua error in package.lua at line 80: module 'strict' not found.
  9. 9.0 9.1 Lua error in package.lua at line 80: module 'strict' not found.
  10. 10.0 10.1 Lua error in package.lua at line 80: module 'strict' not found.
  11. 11.0 11.1 11.2 Oracle Am., Inc. v. Google Inc., 872 F. Supp. 2d 974 (N.D. Cal. 2012).
  12. Lua error in package.lua at line 80: module 'strict' not found.
  13. 13.0 13.1 13.2 13.3 Ruling, para 34: " The point of contention between the parties was Google's refusal to make the implementation of its programs compatible with the Java virtual machine or interoperable with other Java programs. Because Sun/Oracle found that position to be anathema to the "write once, run anywhere" philosophy, it did not grant Google a license to use the Java API packages."
  14. 14.0 14.1 14.2 Lua error in package.lua at line 80: module 'strict' not found.
  15. Lua error in package.lua at line 80: module 'strict' not found.
  16. Lua error in package.lua at line 80: module 'strict' not found.
  17. Lua error in package.lua at line 80: module 'strict' not found.
  18. Lua error in package.lua at line 80: module 'strict' not found.
  19. Lua error in package.lua at line 80: module 'strict' not found.
  20. Lua error in package.lua at line 80: module 'strict' not found.
  21. Lua error in package.lua at line 80: module 'strict' not found.
  22. Lua error in package.lua at line 80: module 'strict' not found.
  23. Lua error in package.lua at line 80: module 'strict' not found.
  24. 24.0 24.1 Lua error in package.lua at line 80: module 'strict' not found.
  25. Lua error in package.lua at line 80: module 'strict' not found.
  26. Lua error in package.lua at line 80: module 'strict' not found.
  27. Lua error in package.lua at line 80: module 'strict' not found.
  28. Lua error in package.lua at line 80: module 'strict' not found.
  29. Lua error in package.lua at line 80: module 'strict' not found.
  30. Lua error in package.lua at line 80: module 'strict' not found.
  31. US patent 1273709, Yellin, Frank & Tuck, Richard D, "Method and system for performing static initialization", issued 2000-05-09, assigned to Sun Microsystems and Oracle 
  32. US Patent No. RE549416 , Gosling, James, "Method and apparatus for resolving data references in generated code", issued 2003-04-29, assigned to Sun Microsystems and Oracle
  33. Lua error in package.lua at line 80: module 'strict' not found.
  34. Lua error in package.lua at line 80: module 'strict' not found.
  35. Lua error in package.lua at line 80: module 'strict' not found.
  36. Lua error in package.lua at line 80: module 'strict' not found.
  37. Lua error in package.lua at line 80: module 'strict' not found.
  38. Lua error in package.lua at line 80: module 'strict' not found.
  39. Lua error in package.lua at line 80: module 'strict' not found.
  40. Lua error in package.lua at line 80: module 'strict' not found.
  41. Lua error in package.lua at line 80: module 'strict' not found.
  42. Lua error in package.lua at line 80: module 'strict' not found.
  43. Lua error in package.lua at line 80: module 'strict' not found.
  44. 44.0 44.1 Oracle Am., Inc. v. Google Inc., 750 F.3d 3303 (Fed. Cir. 2014).
  45. Lua error in package.lua at line 80: module 'strict' not found.
  46. Lua error in package.lua at line 80: module 'strict' not found.
  47. 135 S. Ct. 2887 (2015), Lua error in package.lua at line 80: module 'strict' not found.
  48. Lua error in package.lua at line 80: module 'strict' not found.
  49. Lua error in package.lua at line 80: module 'strict' not found.
  50. Lua error in package.lua at line 80: module 'strict' not found.
  51. Lua error in package.lua at line 80: module 'strict' not found.
  52. Lua error in package.lua at line 80: module 'strict' not found.
  53. Lua error in package.lua at line 80: module 'strict' not found.
  54. Lua error in package.lua at line 80: module 'strict' not found.
  55. Lua error in package.lua at line 80: module 'strict' not found.
  56. Lua error in package.lua at line 80: module 'strict' not found.
  57. Lua error in package.lua at line 80: module 'strict' not found.
  58. Oracle Am., Inc. v. Google Inc., No. 3:10-cv-03561 1988 (N.D. Cal. Jun. 8, 2016).
  59. Oracle Am., Inc. v. Google Inc., No. 3:10-cv-03561 2070 (N.D. Cal. Sept. 27, 2016).
  60. Lua error in package.lua at line 80: module 'strict' not found.
  61. Lua error in package.lua at line 80: module 'strict' not found.
  62. 62.0 62.1 62.2 62.3 62.4 62.5 62.6 Oracle Am., Inc. v. Google Inc., 886 F.3d 1179 (Fed. Cir. 2018).
  63. 63.0 63.1 Lua error in package.lua at line 80: module 'strict' not found.
  64. (p.9 2017-118, 207-102)
  65. 65.0 65.1 Lua error in package.lua at line 80: module 'strict' not found.
  66. Lua error in package.lua at line 80: module 'strict' not found.
  67. Lua error in package.lua at line 80: module 'strict' not found.
  68. Lua error in package.lua at line 80: module 'strict' not found.
  69. Lua error in package.lua at line 80: module 'strict' not found.
  70. Lua error in package.lua at line 80: module 'strict' not found.
  71. Lua error in package.lua at line 80: module 'strict' not found.
  72. Lua error in package.lua at line 80: module 'strict' not found.
  73. Lua error in package.lua at line 80: module 'strict' not found.
  74. Lua error in package.lua at line 80: module 'strict' not found.
  75. Lua error in package.lua at line 80: module 'strict' not found.
  76. 76.0 76.1 Lua error in package.lua at line 80: module 'strict' not found.
  77. 77.0 77.1 Lua error in package.lua at line 80: module 'strict' not found.
  78. Lua error in package.lua at line 80: module 'strict' not found.
  79. 79.0 79.1 79.2 79.3 Lua error in package.lua at line 80: module 'strict' not found.
  80. 80.0 80.1 80.2 80.3 80.4 Lua error in package.lua at line 80: module 'strict' not found.
  81. Lua error in package.lua at line 80: module 'strict' not found.
  82. Lua error in package.lua at line 80: module 'strict' not found.
  83. Lua error in package.lua at line 80: module 'strict' not found.
  84. Lua error in package.lua at line 80: module 'strict' not found.
  85. Lua error in package.lua at line 80: module 'strict' not found.
  86. Lua error in package.lua at line 80: module 'strict' not found.
  87. Lua error in package.lua at line 80: module 'strict' not found.
  88. Lua error in package.lua at line 80: module 'strict' not found.
  89. Lua error in package.lua at line 80: module 'strict' not found.
  90. Lua error in package.lua at line 80: module 'strict' not found.

External links