Google LLC v. Oracle America, Inc. , 593 US ___ (2021),[1]fue una decisión de la Corte Suprema de los Estados Unidos relacionada con la naturaleza delcódigo informáticoyla ley de derechos de autor. La disputa se centró en el uso de partes de lasinterfaces de programación de aplicaciones(API)dellenguaje de programación Javacódigo fuente, que son propiedad deOracle(a través de la subsidiaria, Oracle America, Inc., originada enSun Microsystems), dentro de las primeras versiones delsistema operativo AndroiddeGoogle. Desde entonces, Google ha hecho la transición de Android a un motor sin derechos de autor sin el código fuente, y ha admitido haber usado las API, pero afirmó que esto estaba dentro deluso legítimo.
Oracle inició la demanda argumentando que las API eran susceptibles de derechos de autor, y solicitaba 8.800 millones de dólares en daños y perjuicios por las ventas y licencias de Google de las versiones infractoras anteriores de Android. Si bien dos juicios con jurado a nivel de tribunal de distrito fallaron a favor de Google, el tribunal del Circuito Federal revocó ambas decisiones, sosteniendo que las API son susceptibles de derechos de autor en 2014 y que el uso de Google no cae dentro del uso justo en 2018. Google solicitó con éxito a la Corte Suprema que escuchara el caso en el período de 2019, centrándose en la capacidad de protección de los derechos de autor de las API y el uso justo posterior; el caso se retrasó hasta el período de 2020 debido a la pandemia de COVID-19 . En abril de 2021, la Corte Suprema dictaminó en una decisión de 6 a 2 que el uso de Google de las API de Java cumplía una función organizadora y se encontraba dentro de los cuatro factores del uso justo, pasando por alto la cuestión de la capacidad de protección de los derechos de autor de las API. La decisión revocó el fallo del Circuito Federal y remitió el caso para una revisión adicional.
El caso ha sido de gran interés dentro de las industrias de tecnología y software, ya que numerosos programas de computadora y bibliotecas de software, particularmente en código abierto , se desarrollan recreando la funcionalidad de las API de productos comerciales o de la competencia para ayudar a los desarrolladores en la interoperabilidad entre diferentes sistemas o plataformas.
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 usar 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 cualquier necesidad de que el programador sepa cómo la biblioteca que está usando hace lo que hace. Estas bibliotecas juntas proporcionan la "máquina virtual Java" en la que los programadores escriben programas para usar (ejecutar). La forma común en que se usa un conjunto común de bibliotecas en todas las "máquinas virtuales Java" permite la interoperabilidad , o como lo comercializa Sun, " Escribir una vez, ejecutar 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 fue lanzado al público en 1995, bajo la Sun Community Source License , haciendo que el código fuente estuviera disponible libremente pero requiriendo que los productos que usaran el código se mantuvieran según el estándar Java, y que cualquier trabajo derivado comercial fuera licenciado por Sun. [4] [5] Si bien cualquiera podía programar en el lenguaje en sí, Sun mantenía las bibliotecas Java Platform, Standard Edition (Java SE) y Mobile Edition (Java ME), proporcionadas a los usuarios como bytecode Java precompilado , y sus respectivas API, así como los Technology Compatibility Kits (TCK) que probaban una implementación contra 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 de GNU con una "excepción de classpath" , permitiendo a los desarrolladores el acceso necesario para hacer trabajos derivados y la capacidad de lanzar aplicaciones bajo una licencia diferente. Esto condujo al OpenJDK (Open Java Development Kit), lanzado por primera vez en 2007. Sun mantuvo un fuerte control sobre el lenguaje y los estándares en sí, licenciando los elementos necesarios como TCK para usuarios comerciales. [5] En este momento, el modelo de negocios de Sun cambió para centrarse en la concesión de licencias de la plataforma Java a dispositivos integrados , particularmente teléfonos móviles, y ya había hecho 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 telefonía móvil . [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, sobre la concesión de licencias de las bibliotecas Java para su uso en Android. Sun ofreció un acuerdo de licencia de entre 30 y 50 millones de dólares . Schmidt dijo que Google habría pagado por esa licencia, pero les preocupaba que Sun también hubiera solicitado algún control compartido de Android junto con la tarifa. [10] [11] [12] Google afirma que querían más control para abrir 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 crear una versión de Google del lenguaje con Java y evitar que fuera interoperable con otras versiones, una idea que era "anatema" para el principio de "escribir una vez y ejecutar en cualquier lugar" del lenguaje. [13] Debido a estas diferencias de opinión, las negociaciones no lograron llegar 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 o completa como la Java Standard Edition. [14] En lugar de licenciar Java, Google optó por desarrollar una versión de sala limpia de las bibliotecas de Java Standard Edition, desarrollando las bibliotecas desde un comienzo completamente nuevo sin ningún acceso al código de Sun. Esto se convirtió en el motor detrás de la máquina virtual Dalvik de Android , una parte central 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 sala limpia de código abierto desarrollada por la Apache Software Foundation (ASF). Antes de esto, la ASF había intentado obtener las licencias necesarias de Sun para respaldar el proyecto Apache Harmony y llamarlo una implementación oficial de Java, pero no pudo, en parte debido a la licencia incompatible con la Licencia Pública General GNU de Java y la Licencia Apache de la ASF , ni pudo obtener acceso a los TCK de Java para validar el proyecto Harmony contra 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 el "trabajo pesado" de recrear el código. [13] ASF dejó de mantener Apache Harmony en 2011, lo que llevó a Google a hacerse cargo del 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 señalaron incluía algunas tecnologías Java. [17] [18] [19] El presidente de Sun, Schwartz, felicitó a Google el mismo día, diciendo que habían "atado otro conjunto de cohetes al impulso de la comunidad y a la oportunidad de definir la visión 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 pasado por alto sus requisitos de licencia, "decidimos apretar los dientes 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 7.400 millones de dólares y completó la adquisición en enero de 2010. [21] Además de permitirles entrar en el negocio del hardware, el director ejecutivo de Oracle, Larry Ellison, calificó el lenguaje Java como "el activo de software más importante que hemos adquirido jamás". [22] Oracle continuó desarrollando Java y buscando oportunidades de licencia tras la adquisición de Sun.
Con el lanzamiento de Android KitKat (v4.4) en 2013, Google eliminó la máquina virtual Dalvik y la reemplazó con Android Runtime , que había sido creado dentro de Google sin ninguno de los códigos fuente de Java. [23] Sin embargo, Android continuó usando las API de JavaSE durante la extensión del litigio del caso hasta Android Nougat, cuando fue completamente reemplazado por OpenJDK . [24] [25]
La primera fase del caso duró de 2010 a 2015. Oracle logró establecer con éxito que las API están sujetas a derechos de autor, pero sus reclamos por violación de patentes fueron rechazados.
El 13 de agosto de 2010, Oracle demandó a Google por violación de derechos de autor y patentes en el Tribunal de Distrito del Distrito Norte de California . Oracle afirmó que Google sabía que habían desarrollado Android sin una licencia de Java y habían 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 Oracle relacionadas con la tecnología Java creada por Sun que Google debería haber conocido, ya que habían contratado a antiguos desarrolladores de Sun que trabajaban en Java. Oracle solicitó daños monetarios y una orden judicial para impedir que Google utilizara los materiales supuestamente infractores. [26] [27]
El caso fue asignado al juez William Alsup , quien dividió el caso en tres fases: derechos de autor, patente y daños.
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 Java (API) y la documentación de la API.
Oracle alegó la infracción de 37 API de Java independientes que se habían derivado del proyecto Apache Harmony. [11] Después de dos semanas de testimonio, el jurado determinó el 7 de mayo de 2012 que Google había infringido los derechos de autor relacionados con el código, SSO y documentación de las API, así como la función rangeCheck , pero no se puso de acuerdo sobre si estos usos entraban dentro del 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 necesitaban licenciar Java de Sun u Oracle, pero no se basaron 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 ya que el jurado estaba dividido, así como para revocar la decisión del jurado sobre ocho archivos relacionados con la seguridad que habían revisado y encontrado que no infringían, pero que Google había declarado haber copiado textualmente; Alsup estuvo de acuerdo. Google solicitó una JMOL similar relacionada con rangeCheck , pero Alsup rechazó esta solicitud. [29]
La fase de patentes comenzó el 7 de mayo de 2012, con el mismo jurado. [30] En 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 para optimizar la inicialización estática, en lugar de "simular la ejecución" como lo 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 determinó que no había infracción en ninguna de las reivindicaciones de patente. [33] [34] [35]
El juez Alsup emitió el veredicto final para ambas fases el 31 de mayo de 2012. Si bien el jurado había fallado a favor de Oracle en relación con la infracción de los derechos de autor de las API, Alsup determinó que, en primer lugar, las API no eran susceptibles de protección por derechos de autor:
Siempre que el código específico utilizado para implementar un método sea diferente, cualquiera tiene la libertad, en virtud de 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 las líneas de declaración o de encabezado del método sean idénticas. [11]
Alsup estuvo de acuerdo con el jurado en que la función rangeCheck y los ocho archivos de seguridad constituían una infracción de derechos de autor, pero la única compensación disponible era una indemnización por daños y perjuicios por un máximo de 150.000 dólares estadounidenses [36] [37]
Como resultado de estas sentencias y de una estipulación, no hubo una fase de indemnización por daños y perjuicios ante el jurado. Las partes acordaron no pagar ningún dólar en concepto de daños y perjuicios legales por la pequeña cantidad de código copiado antes de junio de 2012. [38] [39]
Poco después de la conclusión del caso en el Tribunal de Distrito, ambas partes intentaron presentar JMOL adicionales sobre elementos de la sentencia que Alsup desestimó, lo que llevó a Oracle a apelar la decisión y a Google a presentar una contraapelación sobre la demanda de copia literal. Debido a que el caso involucraba demandas relacionadas con patentes, la apelación se asignó 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 dictó el 9 de mayo de 2014. [44]
El tribunal señaló que la Ley de Derechos de Autor brinda protección a "obras originales de autoría fijadas en cualquier medio tangible de expresión" (p. 17). La historia legislativa explica que las obras literarias incluyen "programas informáticos en la medida en que incorporen 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 los derechos de autor, una obra debe ser original. 17 USC § 102(a). Por lo tanto, el tribunal fue "el primero en 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 la cuestión central, sosteniendo que la "estructura, secuencia y organización" de una API son susceptibles de 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 por parte de Google era aceptable de todos modos, según la doctrina del uso justo, ya que el caso original no había puesto de manifiesto los hechos relacionados con el uso justo de manera suficiente para que el Tribunal de Apelaciones se pronunciara sobre ese punto. [44] [45]
En octubre de 2014, Google solicitó a la Corte Suprema de Estados Unidos que escuchara el caso; [46] esta solicitud fue denegada en junio de 2015. [47]
Como lo ordenó 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 fueron de uso justo dada la decisión anterior de que las API eran susceptibles de derechos de autor. [48] [49] Los argumentos finales se completaron el 23 de mayo de 2016 y el jurado comenzó las deliberaciones. Oracle estaba solicitando daños y perjuicios de hasta US$9 mil millones. [50] [51] [52] [53] [54] [55] El 26 de mayo de 2016, el jurado encontró que Android no infringió los derechos de autor 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, [57] pero antes de hacerlo, intentó mociones infructuosas para ignorar el veredicto del jurado , [58] y luego celebrar un nuevo juicio. [59] [60] Oracle presentó oficialmente su apelación el 26 de octubre de 2016. [61]
La apelación de Oracle fue vista 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. [62] El fallo analizó los aspectos de una demanda de uso justo que debían ser decididos por un juez y un jurado, respectivamente. Luego examinó las cuestiones fácticas a las que, se debía asumir, había llegado el jurado, y sus implicaciones en derecho. [62] Señaló que en un caso "mixto" de hechos y derechos, como la presente disputa, el papel del jurado del juicio 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:
[e]n verdad, en literatura, ciencia y arte hay, y puede haber, pocas cosas, si es que hay 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 usar mucho de lo que ya era bien conocido y usado. (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 se refería a 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) determinar 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 que se debe responder" (Decisión p. 19). Salvo error claro, el papel del jurado se limita a determinar "hechos históricos" en disputa (2). Los hechos no se discuten. "Es indiscutible que Google copió textualmente el código declarativo de los 37 paquetes de API de Java, 11.500 líneas del código protegido por derechos de autor de Oracle. También copió el SSO de los paquetes de API de Java. (Decisión p. 10)". También se establece y Google reconoce que el software copiado es creativo y original.
El Tribunal consideró que, como cuestión de derecho, el uso de Java por parte de Google no podía haber entrado dentro de un uso legítimo, incluso si todos los asuntos fácticos decididos por el jurado hubieran sido a favor de Google. El Tribunal de Apelaciones consideró que el uso de las declaraciones de código API por parte de Google no había cumplido ninguno de los cuatro criterios actuales de uso legítimo, sino que era simplemente una reutilización sin transformar. No había sido transformador, ya que se utilizó para los mismos fines sin siquiera cambios o reescrituras mínimas. No fue mínimo, ya que se acordó que solo 170 líneas de las 11.500 líneas copiadas eran necesarias para los fines de Google. No estaba dentro de ningún ejemplo de transformación, ni tenía la intención de permitir la interoperabilidad de terceros, ya que Google no había hecho esfuerzos sustanciales para usarlos para el propósito de la interoperabilidad de terceros. (De hecho, consideró que Google había tratado de evitar la interoperabilidad con otros Java y Sun le había negado previamente una licencia por esa razón. [13] ) Tampoco fue transformador en el sentido de una nueva plataforma, ya que otros teléfonos inteligentes Java precedieron a Android. [62] Era plausible que el uso hubiera perjudicado a Sun/Oracle –quizás en gran medida si se le daba crédito a Oracle– ya que, como resultado, los vendedores comenzaron a esperar que Oracle compitiera en precio con un derivado de su propio lenguaje disponible gratuitamente, y a exigir descuentos muy pronunciados y términos contractuales no deseados. [62] Por lo tanto, el uso que hizo Google del código Java y las API no cumplió con los cuatro criterios actualmente aceptados bajo los cuales sería posible un uso justo. [62]
En cambio, el Tribunal consideró que el propósito de Google había sido mejorar el atractivo de su naciente plataforma Android para los desarrolladores existentes, que a menudo estaban familiarizados con Java, y evitar el "trabajo pesado" de reescribir el código (que podrían haber hecho) necesario para implementar las 170 líneas de detalles de la API que de hecho eran necesarias. "Hacerlo fácil para uno mismo", señaló el Tribunal, está bien establecido que no se encuentra dentro de los motivos válidos para el uso justo. El Tribunal consideró que "el hecho de que Android sea gratuito no hace que el uso que hace Google de los paquetes de la API de Java no sea comercial". [63] Oracle
Oracle ha ideado un sistema de licencias para atraer a los programadores y comercializar simultáneamente la plataforma. En la parte relevante, Oracle cobra una tarifa de licencia a quienes desean utilizar las API en una plataforma competidora 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. [64]
El propósito era comercial, los hechos históricos establecidos por el jurado no satisfacían ninguno de los criterios de uso justo, [62] y el Tribunal devolvió el caso al Tribunal de Distrito del Distrito Norte de California para determinar el monto del daño que Google debía pagar a Oracle. [63]
En enero de 2019, Google presentó una petición de auto de certiorari ante la Corte Suprema de los Estados Unidos para impugnar los dos fallos que el tribunal de apelaciones dictó a favor de Oracle. En su petición, Google centró su caso en si los derechos de autor se extienden a una interfaz de software como una API y si el uso de la API de Java por parte de Google se encontraba dentro del uso justo como se encontró en los juicios con jurado. [65] En órdenes emitidas en abril de 2019, la Corte solicitó al Procurador General de los Estados Unidos que presentara un escrito amicus curiae para describir la postura del gobierno sobre el caso. [66] La administración Trump respaldó a Oracle e instó a la Corte a denegar el certiorari. Microsoft , Mozilla Corporation , Red Hat Inc. y otros presentaron escritos amicus curiae en apoyo de la posición de Google. [67] IBM , la Asociación de la Industria de Computación y Comunicaciones , la Asociación de Internet , la Asociación de Cuidado Automotriz y un grupo colectivo de más de 150 académicos y profesionales de la informática también presentaron informes apoyando la postura de Google, advirtiendo que una decisión a favor de Oracle dañaría al mundo de la informática en su conjunto. [68]
La Corte Suprema concedió el certiorari el 15 de noviembre de 2019, y se esperaba que escuchara el caso el 24 de marzo de 2020. [69] [70] [71] Sin embargo, la Corte Suprema pospuso su sesión de argumentos de marzo el 16 de marzo a la luz de las preocupaciones en torno al COVID-19 , y más tarde anunció que Google v. Oracle era uno de varios casos del período 2019-20 que se pospondrían hasta la primera semana del período 2020-21. [72] [73] [74] Tras la demora, la Corte pidió a las partes que presentaran escritos adicionales relacionados con la Séptima Enmienda , dado que el tribunal del Distrito Federal había anulado algunas de las conclusiones de hechos que el jurado había concluido en su caso a nivel de Distrito. [75]
Los argumentos orales se escucharon por teleconferencia debido a la pandemia de COVID-19 en curso el 7 de octubre de 2020. [76] La jueza Ruth Bader Ginsburg había fallecido el mes anterior y su reemplazo, la jueza Amy Coney Barrett , aún no había sido confirmado, por lo que Barrett no participó en los procedimientos. [77] Los observadores de la corte encontraron que, si bien los jueces parecían ponerse del lado de Oracle en los argumentos de derechos de autor, también tomaron deferencia a los argumentos presentados por Microsoft, que se había puesto del lado de Google en el caso. Microsoft argumentó en un escrito amicus que fallar a favor de Oracle podría trastornar la industria del software. Varias preguntas se centraron en cómo las API caían dentro de la distinción idea-expresión de los derechos de autor y si se aplicaría la doctrina de la fusión . También se vio que la jueza Gorsuch se centró en gran medida en los argumentos de la Séptima Enmienda y en si la decisión del Circuito Federal de revocar el veredicto del jurado del tribunal de primera instancia era adecuada. [76] [78]
El Tribunal emitió su decisión el 5 de abril de 2021. Por una mayoría de 6 a 2, el Tribunal dictaminó que el uso de las API de Java por parte de Google estaba dentro de los límites del uso justo, revirtiendo el fallo del Tribunal de Apelaciones del Circuito Federal y remitiendo el caso para una nueva audiencia. El juez Stephen Breyer escribió la opinión mayoritaria. La opinión de Breyer comenzó con la suposición de que las API podrían estar sujetas a derechos de autor y, por lo tanto, procedió a una revisión de los cuatro factores que contribuyeron al uso justo: [79] [80]
Breyer determinó que el uso de las API por parte de Google había cumplido con los cuatro factores y que Google utilizó "solo lo necesario para permitir a los usuarios poner a trabajar sus talentos acumulados en un programa nuevo y transformador". [79] Breyer concluyó que "sostenemos que la copia en cuestión constituyó, no obstante, un uso justo. Por lo tanto, la copia de Google no violó la ley de derechos de autor". [77] Esta conclusión hizo innecesaria la necesidad de evaluar los derechos de autor de la API. [79]
El juez Clarence Thomas escribió una opinión disidente a la que se sumó el juez Samuel Alito . [82] Thomas escribió que la opinión mayoritaria creó una nueva distinción entre implementar código y declarar código 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 declarar código permanezca protegido por derechos de autor". [24] Thomas afirmó además que en su propio análisis de uso justo "el uso que hizo Google de ese código protegido por derechos de autor fue todo menos justo". [83]
El caso de Google contra Oracle fue seguido de cerca por la industria tecnológica. Un fallo a favor de Oracle podría haber tenido efectos significativos en el desarrollo de software pasado y futuro dado el uso prolífico de las API. [84] Los opositores al fallo del Circuito Federal, incluidos Google y otros desarrolladores de software basado en Android, habían planteado varias preocupaciones, incluido el impacto en la interoperabilidad , la innovación de software y la posibilidad de que los malos actores se apropien de los derechos de software antiguo y presenten demandas contra las empresas que construyeron su software sobre lo que se suponía que eran estándares abiertos. Si las API quedaran sujetas a la protección de los derechos de autor, se cree que las empresas necesitarían implementar estándares deliberadamente incompatibles para protegerse del riesgo de litigios complejos . Este escenario significaría alejarse de las tendencias actuales en el desarrollo de software que se han centrado en mejorar la interoperabilidad entre diferentes servicios, permitir que las aplicaciones se comuniquen entre sí y crear plataformas más integradas para los usuarios finales. [65] [14]
Los expertos legales y de la industria afirmaron que una victoria de Oracle podría haber creado un efecto paralizante en el desarrollo de software, con los titulares de derechos de autor utilizando los derechos de autor sobre las API para evitar su uso en el desarrollo de alternativas interoperables a través de ingeniería inversa , tan común en el desarrollo de software de código abierto. [85] [86] [87] Al mismo tiempo, los expertos advirtieron que una sentencia que favorezca la posición de Google puede debilitar la protección de los derechos de autor para los desarrolladores de código de software, permitiendo a los competidores con mejores recursos desarrollar productos mejorados de empresas más pequeñas y reducir el motivo de innovación dentro de la industria. [88] [89]
Un ejemplo identificado por Wired es el sistema operativo Linux . Si bien Linux es completamente de código abierto , se basa en POSIX , un conjunto de API que imitan las del sistema operativo comercial Unix y que permiten altos niveles de interoperabilidad para los desarrolladores; un programador solo necesitaría escribir un conjunto de código que luego se puede compilar en cualquier sistema que tenga la misma API, incluso si la arquitectura informática de los sistemas es diferente. Si la jurisprudencia hubiera favorecido a Oracle, los propietarios de versiones anteriores de Unix, Micro Focus , podrían haber reclamado daños y perjuicios a cualquier desarrollador de sistemas operativos basados en POSIX que tuviera la intención de utilizar el sistema operativo para uso comercial. [90]
En lo que podría ser un movimiento clave en su naciente estrategia inalámbrica, Google (GOOG) ha adquirido silenciosamente la startup Android Inc. ...