Google LLC contra Oracle America, Inc.

Java fue desarrollado originalmente en Sun Microsystems a partir de diciembre de 1990. ^{[ 2 ]} Incluía un nuevo lenguaje de programación , una máquina virtual y un conjunto de bibliotecas para su uso con el lenguaje. ^{[ 3 ]} Estas bibliotecas están documentadas para los programadores a través de interfaces de programación de aplicaciones (API), que les indican qué información proporcionar a las funciones de la biblioteca y qué resultados esperar, eliminando la necesidad de que el programador sepa cómo funciona la biblioteca que está utilizando. Estas bibliotecas, en conjunto, proporcionan la "máquina virtual Java" sobre la cual los programadores escriben programas para su uso (ejecución). La forma común en que se utiliza un conjunto común de bibliotecas en todas las "máquinas virtuales Java" permite la interoperabilidad , o como lo promociona Sun, " Escribe una vez, ejecuta en cualquier lugar "; un programador solo necesita crear una versión de su software que, debido al único grupo de API comunes a todas las máquinas virtuales Java, puede ejecutarse en cualquier plataforma informática que admita Java.

El lenguaje Java se lanzó al público en 1995, bajo la Licencia de Código Fuente de la Comunidad Sun , lo que hizo que el código fuente estuviera disponible libremente pero requirió que los productos que usaran el código se mantuvieran según el estándar Java, y que cualquier obra derivada comercial fuera licenciada por Sun. ^{[ 4 ] [ 5 ]} Si bien cualquiera podía programar en el lenguaje en sí, Sun mantuvo las bibliotecas de la Plataforma Java, Edición Estándar (Java SE) y Edición Móvil (Java ME), proporcionadas a los usuarios como bytecode Java precompilado , y sus respectivas API, así como los Kits de Compatibilidad Tecnológica (TCK) que probaban una implementación según el estándar Java. ^{[ 6 ]} Durante 2006 y 2007, debido a la presión de los desarrolladores, Sun cambió la licencia de los diversos paquetes Java para usar la Licencia Pública General GNU con una "excepción de classpath" , lo que permitió a los desarrolladores el acceso necesario para hacer obras derivadas y la capacidad de lanzar aplicaciones bajo una licencia diferente. Esto dio lugar al OpenJDK (Open Java Development Kit), lanzado por primera vez en 2007. Sun mantuvo un fuerte control sobre el lenguaje y los estándares, licenciando los elementos necesarios, como los TCK, para usuarios comerciales. ^{[ 5 ]} En ese momento, el modelo de negocio de Sun cambió para centrarse en la concesión de licencias de la plataforma Java para dispositivos integrados , en particular teléfonos móviles, y ya había firmado acuerdos de licencia con Nokia , Motorola y Research In Motion . ^{[ 7 ]}

Android, Inc. fue fundada en 2003 por Andy Rubin , Rich Miner , Nick Sears y Chris White para desarrollar una plataforma de teléfonos móviles . ^{[ 8 ] [ 9 ]} Google compró Android en 2005 y continuó desarrollando el sistema operativo Android . ^{[ 9 ]} Durante el desarrollo de Android, Google quería incorporar las bibliotecas Java SE. El presidente ejecutivo de Google, Eric Schmidt, se había acercado al presidente de Sun, Jonathan I. Schwartz, para licenciar las bibliotecas Java para su uso en Android. Sun ofreció un acuerdo de licencia de entre US$30 y 50 millones . Schmidt dijo que Google habría pagado por esa licencia, pero les preocupaba que Sun también hubiera solicitado cierto control compartido de Android junto con la tarifa. ^{[ 10 ] [ 11 ] [ 12 ]} Google afirma que querían más control para liberar el código fuente del lenguaje y permitir que terceros aprovecharan mejor su código; ^{[ 10 ]} Oracle afirma que Sun se negó porque la intención de Google era esencialmente bifurcar Java a una versión de Google del lenguaje, e impedir que fuera interoperable con otras versiones, una idea que era "anatema" para la base del lenguaje de "escribir una vez, ejecutar en cualquier lugar". ^{[ 13 ]} Debido a estas diferencias de opinión, las negociaciones no llegaron a un acuerdo y Sun le negó a Google una licencia para Java. ^{[ 13 ]}

En ese momento, la implementación de OpenJDK ofrecida por Sun no era tan madura ni completa como la Java Standard Edition. ^{[ 14 ]} En lugar de licenciar Java, Google optó por desarrollar una versión limpia de las bibliotecas de la Java Standard Edition, desarrollándolas desde cero sin acceso al código de Sun. Esto se convirtió en el motor de la máquina virtual Dalvik de Android , una parte fundamental del nuevo sistema. Parte de la máquina virtual incluía 37 llamadas a la API y alrededor de 11.500 líneas de código consideradas centrales para Java, que se tomaron de Apache Harmony , una implementación de Java de código abierto desarrollada por la Apache Software Foundation (ASF). Anteriormente, la ASF había intentado obtener las licencias necesarias de Sun para respaldar el proyecto Apache Harmony y considerarlo una implementación oficial de Java, pero no pudo, en parte debido a la incompatibilidad de licencias con la Licencia Pública General GNU de Java y la Licencia Apache de la ASF , ni tampoco pudo obtener acceso a los TCK de Java para validar el proyecto Harmony con la implementación de Sun. ^{[ 15 ] [ 16 ]} Aunque Google declaró que utilizó este código para garantizar la interoperabilidad con Java Standard Edition para otros programadores, ^{[ 6 ]} durante la segunda audiencia de apelación, Google declaró que había utilizado este código por razones comerciales para completar rápidamente Android y evitar la "tarde" de recrear el código. ^{[ 13 ]} ASF dejó de mantener Apache Harmony en 2011, lo que llevó a Google a asumir el mantenimiento de estas bibliotecas. ^{[ 14 ]}

Google lanzó una versión beta de la plataforma Android el 5 de noviembre de 2007 y, una semana después, el kit de desarrollo de software (SDK), que, según indicaron, incluía algunas tecnologías Java. ^{[ 17 ] [ 18 ] [ 19 ]} El presidente de Sun, Schwartz, felicitó a Google ese mismo día, diciendo que habían "impulsado aún más el dinamismo de la comunidad y la visión que define la oportunidad en nuestro (y otros) planetas". ^{[ 20 ]} Durante la prueba, Schwartz dijo que en ese momento del lanzamiento de Android, a pesar de saber que Google podría haber eludido sus requisitos de licencia, "decidimos armarnos de valor y apoyarlo para que cualquiera que lo apoyara nos viera como parte de la cadena de valor". ^{[ 7 ]} 

Oracle anunció que compraría Sun en abril de 2009 por US$7.4 mil millones y completó la adquisición en enero de 2010. ^{[ 21 ]} Además de permitirles ingresar al negocio del hardware, el CEO de Oracle, Larry Ellison, calificó al lenguaje Java como "el activo de software más importante que jamás hayamos adquirido". ^{[ 22 ]} Oracle continuó desarrollando Java y buscando oportunidades de licenciamiento después de su adquisición de Sun.

Con el lanzamiento de Android Lollipop (v5.0) en 2014, Google eliminó la máquina virtual Dalvik y la reemplazó con Android Runtime , que había sido compilado dentro de Google sin ningún código fuente de Java. ^{[ 23 ] [ 24 ]} Sin embargo, Android continuó utilizando las API de JavaSE durante todo el litigio del caso hasta Android Nougat, cuando fue reemplazada por completo por OpenJDK . ^{[ 25 ] [ 14 ]}

El 13 de agosto de 2010, Oracle demandó a Google por infracción de derechos de autor y patentes ante el Tribunal de Distrito del Distrito Norte de California . Oracle alegó que Google sabía que había desarrollado Android sin una licencia de Java y que había copiado sus API, y que, por lo tanto, Google había infringido los derechos de autor de Oracle. Oracle también citó siete patentes anteriores de su propiedad relacionadas con la tecnología Java creada por Sun, de las cuales Google debería haber tenido conocimiento, ya que había contratado a antiguos desarrolladores de Sun que trabajaban en Java. Oracle solicitó una indemnización por daños y perjuicios y una orden judicial para impedir que Google utilizara el material supuestamente infractor. ^{[ 26 ] [ 27 ]}

El caso fue asignado al juez William Alsup , quien lo dividió en tres fases: derechos de autor, patentes y daños y perjuicios.

La fase de derechos de autor comenzó el 16 de abril de 2012 y consistió en varias reclamaciones distintas de infracción: una función rangeCheck de nueve líneas , varios archivos de prueba, la estructura, secuencia y organización (SSO) de la API de Java y la documentación de la API.

Oracle alegó infracción de 37 API de Java separadas que habían derivado del proyecto Apache Harmony. ^{[ 11 ]} Después de dos semanas de testimonio, el jurado dictaminó el 7 de mayo de 2012 que Google había infringido los derechos de autor relacionados con el código, SSO y la documentación de las API, así como la función rangeCheck , pero no llegó a un acuerdo sobre si estos usos se ajustaban al uso legítimo. El jurado también determinó que Google tenía motivos suficientes para creer, basándose en la conducta de Sun y Oracle, que no necesitaba licenciar Java de Sun ni de Oracle, pero no se basó en esto al desarrollar Android. ^{[ 28 ]} Oracle solicitó una sentencia como cuestión de derecho (JMOL) para que el caso desestimara cualquier defensa de uso legítimo dado que el jurado estaba dividido, así como para que se revocara la decisión del jurado sobre ocho archivos relacionados con la seguridad que habían revisado y considerado no infractores, pero que Google había declarado haber copiado textualmente; Alsup estuvo de acuerdo. Google solicitó una JMOL similar relacionada con rangeCheck , pero Alsup denegó esta solicitud. ^{[ 29 ]}

La fase de patentes comenzó el 7 de mayo de 2012, con el mismo jurado. ^{[ 30 ]} Para el momento del juicio, el caso de patentes de Oracle comprendía reivindicaciones de dos patentes, 6,061,520 (Método y sistema para realizar inicialización estática), ^{[ 31 ]} (la patente '520) y RE38104 (Método y aparato para resolver referencias de datos en código generado). ^{[ 32 ]} (la patente '104). Google presentó una defensa de no infracción. Para la patente '520, argumentaron que estaban utilizando el análisis sintáctico para optimizar la inicialización estática, en lugar de "simular la ejecución" como requería la reivindicación. Para la patente '104, argumentaron que la instrucción no incluía una referencia simbólica. El 23 de mayo de 2012, el jurado dictaminó que no había infracción en todas las reivindicaciones de patentes. ^{[ 33 ] [ 34 ] [ 35 ]}

El juez Alsup emitió el veredicto final para ambas fases el 31 de mayo de 2012. Si bien el jurado falló a favor de Oracle en lo que respecta a la infracción de derechos de autor de las API, Alsup determinó que las API no eran susceptibles de protección por derechos de autor en primer lugar:

Siempre que el código específico utilizado para implementar un método sea diferente, cualquier persona es libre, según la Ley de Derechos de Autor , de escribir su propio código para llevar a cabo exactamente la misma función o especificación de cualquier método utilizado en la API de Java. No importa que la declaración o las líneas de encabezado del método sean idénticas. ^{[ 11 ]}

Alsup estuvo de acuerdo con el jurado en que la función rangeCheck y ocho archivos de seguridad eran una infracción de derechos de autor, pero el único recurso disponible eran los daños legales hasta un máximo de US$150,000 ^{[ 36 ] [ 37 ].}

Como resultado de estas resoluciones y un acuerdo, no hubo fase de determinación de daños por parte del jurado. Las partes acordaron pagar cero dólares en concepto de daños legales por la pequeña cantidad de código copiado hasta junio de 2012. ^{[ 38 ] [ 39 ]}

Poco después de la conclusión del caso en el Tribunal de Distrito, ambas partes intentaron presentar mociones de sentencia sumarias adicionales sobre elementos del fallo que Alsup desestimó, lo que llevó a Oracle a apelar la decisión y a Google a presentar una apelación cruzada sobre la reclamación de copia literal. Debido a que el caso involucraba reclamaciones relacionadas con patentes, la apelación fue asignada automáticamente al Tribunal de Apelaciones de los Estados Unidos para el Circuito Federal . ^{[ 40 ] [ 41 ]} La audiencia se celebró el 4 de diciembre de 2013, ^{[ 42 ] [ 43 ]} y la sentencia se emitió el 9 de mayo de 2014. ^{[ 44 ]}

El tribunal señaló que la Ley de Derechos de Autor brinda protección a las "obras originales de autoría fijadas en cualquier soporte tangible de expresión" (p.  17). El historial legislativo explica que las obras literarias incluyen "programas informáticos en la medida en que incorporan la autoría en la expresión de ideas originales del programador, a diferencia de las ideas mismas" (p.  18). Para calificar para la protección de derechos de autor, una obra debe ser original. 17 USC § 102(a). Por lo tanto, el tribunal debía "primero evaluar si la expresión es original del programador" (p.  24), algo que Google ya había admitido (p.  21). Esto llevó al tribunal a concluir "que la estructura general de los paquetes API de Oracle es creativa, original y se asemeja a una taxonomía" (p.  14). Por lo tanto, revocó la decisión del tribunal de distrito sobre el tema central, sosteniendo que la "estructura, secuencia y organización" de una API es protegible por derechos de autor. También falló a favor de Oracle con respecto a la pequeña cantidad de copia literal, sosteniendo que no era de minimis . El caso fue remitido al Tribunal de Distrito para un segundo juicio, para considerar si el uso de Google era aceptable de todos modos, bajo la doctrina del uso legítimo, ya que el caso original no había expuesto los hechos relacionados con el uso legítimo de manera suficiente para que el Tribunal de Apelación se pronunciara sobre ese punto. ^{[ 44 ] [ 45 ]}

En octubre de 2014, Google solicitó a la Corte Suprema de los Estados Unidos que revisara el caso; ^{[ 46 ]} esta solicitud fue denegada en junio de 2015. ^{[ 47 ]}

Según lo ordenado por el Tribunal de Apelaciones, un nuevo juicio en el tribunal de distrito comenzó el 9 de mayo de 2016, sobre la cuestión de si las acciones de Google eran uso justo dado el fallo anterior de que las API eran protegibles por derechos de autor. ^{[ 48 ] [ 49 ]} Los alegatos finales concluyeron el 23 de mayo de 2016 y el jurado comenzó las deliberaciones. Oracle solicitaba daños y perjuicios de hasta US$9 mil millones. ^{[ 50 ] [ 51 ] [ 52 ] [ 53 ] [ 54 ] [ 55 ]} El 26 de mayo de 2016, el jurado determinó que Android no infringía los derechos de autor propiedad de Oracle porque su reimplementación de 37 API de Java estaba protegida por el uso justo. ^{[ 56 ]} Oracle anunció su intención de apelar, ^{[ 56 ]} pero antes de hacerlo, intentó mociones infructuosas para desestimar el veredicto del jurado , ^{[ 57 ]} y luego para celebrar un nuevo juicio. ^{[ 58 ] [ 59 ]} Oracle presentó oficialmente su apelación el 26 de octubre de 2016. ^{[ 60 ]}

La apelación de Oracle fue escuchada por el Tribunal de Apelaciones de los Estados Unidos para el Circuito Federal en 2017. El 27 de marzo de 2018, el Tribunal falló a favor de Oracle. ^{[ 61 ]} El fallo analizó los aspectos de una demanda de uso legítimo que debían ser decididos por un juez y un jurado, respectivamente. Luego examinó los hechos que, se suponía, el jurado había determinado y sus implicaciones legales. ^{[ 61 ]} Señaló que en un caso "mixto" de hechos y derecho, como la presente disputa, el papel del jurado es decidir sobre los hechos. La jueza O'Malley citó el caso de la Corte Suprema Campbell v. Acuff-Rose Music, Inc. 510 U.S. 569 (1994) en su opinión, señalando que:

En verdad, en la literatura, la ciencia y el arte, existen, y pueden existir, pocas cosas, si acaso alguna, que en un sentido abstracto sean estrictamente nuevas y originales. Todo libro de literatura, ciencia y arte toma prestado, y necesariamente debe tomar prestado, y utilizar mucho de lo que ya era bien conocido y utilizado con anterioridad. (Citando a Emerson v. Davies, 8 F. Cas. 615, 619 (CCD Mass. 1845))

El papel del Tribunal de Apelaciones es evaluar si un jurado razonable podría haber llegado a las conclusiones a las que llegó, y si la decisión del juez podría ser correcta y razonable en derecho. La revisión estándar de cuestiones mixtas de derecho y de hecho abarcaba tres componentes: "(1) determinar el estándar legal que rige la cuestión planteada y qué tipos de hechos históricos son relevantes para ese estándar; (2) encontrar cuáles son los hechos históricos en el caso en cuestión; y (3) evaluar si los hechos históricos encontrados satisfacen la prueba legal que rige la cuestión a responder" (Decisión p.  19). Excepto en caso de error manifiesto, el papel del jurado se limita a determinar los "hechos históricos" controvertidos (2). Los hechos no se discuten. "Es indiscutible que Google copió textualmente el código declarativo de los 37 paquetes de la API de Java, 11.500 líneas del código con derechos de autor de Oracle. También copió el SSO de los paquetes de la API de Java. (Decisión p. 10)" También está establecido y Google reconoce que el software copiado es creativo y original.

El Tribunal determinó que, desde un punto de vista legal, el uso de Java por parte de Google no podía considerarse un uso legítimo, incluso si todos los hechos resueltos por el jurado hubieran sido a favor de Google. El Tribunal de Apelaciones concluyó que el uso de las declaraciones de código API por parte de Google no cumplía ninguno de los cuatro criterios vigentes para el uso legítimo, sino que se trataba simplemente de una reutilización sin transformar. No había sido transformador, puesto que se utilizó para los mismos fines sin cambios ni reescrituras mínimas. Tampoco era mínimo, puesto que se acordó que solo 170 de las 11 500 líneas copiadas eran necesarias para los fines de Google. No se ajustaba a ningún ejemplo de transformación, ni tenía como objetivo permitir la interoperabilidad con terceros, puesto que Google no había realizado esfuerzos sustanciales para utilizarlas con ese fin. (De hecho, se constató que Google había intentado impedir la interoperabilidad con otras versiones de Java y que Sun le había denegado previamente una licencia por ese motivo. ^{[ 13 ]} ) Tampoco era transformador en el sentido de una nueva plataforma, puesto que otros teléfonos inteligentes con Java eran anteriores a Android. ^{[ 61 ]} Era plausible que el uso hubiera perjudicado a Sun/Oracle  —quizás en gran medida si se le creyera a Oracle—  , ya ​​que, como resultado, los proveedores comenzaron a esperar que Oracle compitiera en precio con una versión derivada de su propio lenguaje disponible gratuitamente, y que exigiera descuentos muy elevados y condiciones contractuales indeseadas. ^{[ 61 ]} Por lo tanto, el uso que Google hizo del código Java y las API no cumplió con los cuatro criterios actualmente aceptados para que fuera posible el uso legítimo. ^{[ 61 ]}

En cambio, el Tribunal determinó que el propósito de Google había sido aumentar el atractivo de su incipiente plataforma Android para los desarrolladores existentes, quienes a menudo estaban familiarizados con Java, y evitar la "tarde" de reescribir el código (lo cual podrían haber hecho) necesario para implementar las 170 líneas de detalles de la API que, de hecho, eran requeridas. "Facilitar las cosas", señaló el tribunal, no se considera un motivo válido para el uso legítimo. El Tribunal concluyó que "el hecho de que Android sea gratuito no convierte el uso que hace Google de los paquetes de la API de Java en un uso no comercial". ^{[ 62 ]} Oracle

Oracle diseñó un esquema de licencias para atraer programadores y, al mismo tiempo, comercializar la plataforma. En lo que respecta a este tema, Oracle cobra una tarifa de licencia a quienes desean usar las API en una plataforma de la competencia o integrarlas en un dispositivo electrónico. Para preservar la filosofía de "escribir una vez, ejecutar en cualquier lugar", Oracle impone estrictos requisitos de compatibilidad a los licenciatarios. ^{[ 63 ]}

El propósito era comercial, los hechos históricos establecidos por el jurado no satisfacían ninguno de los criterios para el uso legítimo, ^{[ 61 ]} y el Tribunal devolvió el caso al Tribunal de Distrito del Distrito Norte de California para determinar el monto de los daños que Google debería pagar a Oracle. ^{[ 62 ]}

El Tribunal emitió su decisión el 5 de abril de 2021. Por mayoría de 6-2, el Tribunal dictaminó que el uso que Google hacía de las API de Java se encontraba dentro de los límites del uso legítimo, revocando la decisión del Tribunal de Apelaciones del Circuito Federal y remitiendo el caso para una nueva audiencia. El juez Stephen Breyer redactó la opinión mayoritaria. La opinión de Breyer partió de la premisa de que las API podrían estar protegidas por derechos de autor y, por lo tanto, procedió con una revisión de los cuatro factores que contribuyeron al uso legítimo: ^{[ 78 ] [ 79 ]}

1. La naturaleza de la obra protegida por derechos de autor: el análisis de Breyer identificó que las API servían para declarar código en lugar de implementarlo, y que en el contexto de los derechos de autor, cumplían una "función de organización" similar al Sistema Decimal Dewey , en el que el uso legítimo es más aplicable. ^{[ 80 ]}
2. El propósito y el carácter del uso: Breyer afirmó que Google tomó y transformó las API de Java "para ampliar el uso y la utilidad de los teléfonos inteligentes basados ​​en Android", lo que "creó una nueva plataforma que los programadores podían usar fácilmente". ^{[ 79 ]} Breyer también escribió que Google se limitó a usar las API de Java "según fuera necesario para incluir tareas que serían útiles en programas para teléfonos inteligentes". ^{[ 79 ]}
3. La cantidad y la importancia del material protegido por derechos de autor: Breyer afirmó que Google solo utilizó alrededor del 0,4 % del código fuente total de Java, una cantidad mínima. Respecto a la importancia del material, Breyer escribió que Google no copió el código fundamental de la implementación de Java, y que «Google copió esas líneas no por su creatividad, su belleza, ni siquiera (en cierto sentido) por su propósito. Las copió porque los programadores ya habían aprendido a trabajar con [Java SE], y habría sido difícil... atraer programadores a... Android... sin ellas». ^{[ 79 ]}
4. El efecto en el mercado de la apropiación de derechos de autor: Breyer afirmó que, en el momento en que Google copió las API de Java, no estaba claro si Android tendría éxito y no debía considerarse como un sustituto de Java, sino como un producto que operaba en una plataforma diferente. ^{[ 79 ]} Breyer añadió que, si hubieran fallado a favor de Oracle, "se habría puesto en riesgo la reputación pública", ya que "solo Oracle tendría la clave. El resultado bien podría resultar altamente rentable para Oracle (u otras empresas que posean derechos de autor sobre interfaces informáticas)... [pero] el bloqueo interferiría con, y no fomentaría, los objetivos básicos de creatividad de los derechos de autor". ^{[ 78 ]}

Breyer determinó que el uso que Google hizo de las API cumplió con los cuatro factores y que Google utilizó «solo lo necesario para permitir que los usuarios pusieran sus talentos acumulados al servicio de un programa nuevo y transformador». ^{[ 78 ]} Breyer concluyó que «sostenemos que la copia en cuestión constituyó, no obstante, un uso legítimo. Por lo tanto, la copia de Google no violó la ley de derechos de autor». ^{[ 76 ]} Esta conclusión hizo innecesario evaluar los derechos de autor de la API. ^{[ 78 ]}

El juez Clarence Thomas escribió una opinión disidente a la que se unió el juez Samuel Alito . ^{[ 81 ]} Thomas escribió que la opinión mayoritaria creó una nueva distinción entre código de implementación y código de declaración que el Congreso había rechazado y, por lo tanto, "el resultado de este análisis distorsionador es una opinión que hace difícil imaginar cualquier circunstancia en la que el código de declaración permanezca protegido por derechos de autor". ^{[ 25 ]} Thomas afirmó además que en su propio análisis de uso legítimo "el uso que Google hizo de ese código protegido por derechos de autor no fue en absoluto justo". ^{[ 82 ]}