Google LLC contra Oracle America, Inc. , 593 US ___ (2021),[1]fue una decisión de la Corte Suprema de EE. UU. 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 aplicacionesdellenguaje de programación Javay alrededor de 11.000 líneas decódigo fuente, que son propiedad deOracle(a través de su filial Oracle America, Inc., con origen enSun Microsystems). dentro de las primeras versiones delsistema operativo AndroiddeGoogle. Desde entonces, Google ha hecho la transición de Android a un motor libre de derechos de autor y sin el código fuente, y ha admitido haber utilizado las API, pero afirmó que esto estaba dentro deluso legítimo.
Oracle inició la demanda argumentando que las API tenían derechos de autor, solicitando 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 de Circuito Federal revocó ambas decisiones, sosteniendo que las API están sujetas a derechos de autor y que el uso de Google no se considera uso legítimo. Google solicitó con éxito a la Corte Suprema que escuchara el caso en el período de 2019, centrándose en la protección de los derechos de autor de las API y el uso legítimo posterior; el caso fue retrasado hasta la vigencia 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 las API de Java por parte de Google se encontraba dentro de los cuatro factores de uso legítimo, sin pasar por la cuestión de la protección de los derechos de autor de las API. La decisión revocó el fallo del Circuito Federal y devolvió 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 informáticos 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 se desarrolló 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 dicen a los programadores 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á utilizando hace qué. lo hace. Estas bibliotecas juntas proporcionan la "máquina virtual Java" sobre la cual los programadores escriben programas para usar (ejecutar). 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 comercializa Sun, " escribir una vez, ejecutar en cualquier lugar "; un programador sólo necesita crear una versión de su software que, debido al único grupo de API común 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 fuente comunitaria Sun , lo que hizo que el código fuente estuviera disponible gratuitamente pero requería que los productos que usaban el código se mantuvieran según el estándar Java y que cualquier trabajo derivado comercial tuviera licencia de Sun. [4] [5] Si bien cualquiera podía programar en el lenguaje mismo, Sun mantuvo las bibliotecas Java Platform, Standard Edition (Java SE) y Mobile Edition (Java ME), proporcionadas a los usuarios como código de bytes Java precompilado , y sus respectivas API. , así como los kits de compatibilidad tecnológica (TCK) que probaron una implementación con 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 de Java para usar la Licencia Pública General GNU con una "excepción de classpath" , permitiendo a los desarrolladores el acceso necesario para realizar trabajos derivados y la capacidad de lanzar aplicaciones bajo una licencia diferente. Esto llevó al OpenJDK (Open Java Development Kit), lanzado por primera vez en 2007. Sun mantuvo un fuerte control sobre el lenguaje y los estándares, otorgando licencias de los elementos necesarios como TCK para usuarios comerciales. [5] En ese momento, el modelo de negocio de Sun cambió y se centró en la concesión de licencias de la plataforma Java a dispositivos integrados , en particular teléfonos móviles, y ya había cerrado 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 quiso incorporar las bibliotecas Java SE. El presidente ejecutivo de Google, Eric Schmidt, se había acercado al presidente de Sun, Jonathan I. Schwartz, para solicitar la licencia 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 cierto control compartido de Android junto con la tarifa. [10] [11] [12] Google afirma que querían más control para poder abrir el lenguaje y permitir que terceros aprovechen 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 del lenguaje de Google y evitar que fuera interoperable con otras versiones, una idea que era "anatema" para la estrategia "escribir una vez y ejecutar en cualquier lugar". "Base del idioma. [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 ni completa como la edición estándar de Java. [14] En lugar de licenciar Java, Google optó por desarrollar una versión de sala limpia de las bibliotecas Java Standard Edition, desarrollando las bibliotecas desde un comienzo completamente nuevo sin ningún acceso al código de Sun. Este 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 API y alrededor de 11.500 líneas de código consideradas centrales para Java, que fueron tomadas de Apache Harmony , una implementación Java de sala limpia de código abierto desarrollada por Apache Software Foundation (ASF). Antes de esto, la ASF había intentado obtener las licencias necesarias de Sun para respaldar el proyecto Apache Harmony como para llamarlo una implementación oficial de Java, pero no pudo, en parte debido a la incompatibilidad de las licencias 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 frente a 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 para evitar la "pesadilla" 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 visión que define las oportunidades 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 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 ingresar al negocio de hardware, el director ejecutivo de Oracle, Larry Ellison, llamó al lenguaje Java "el activo de software más importante que tenemos". haber adquirido alguna vez". [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 se había creado dentro de Google sin ningún código fuente de Java. [23] Sin embargo, Android continuó usando las API de JavaSE durante todo el 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 estableció con éxito que las API tienen derechos de autor, pero sus reclamaciones por infracción de patente fueron rechazadas.
El 13 de agosto de 2010, Oracle demandó a Google por infracción de derechos de autor y patentes en el Tribunal de Distrito del Distrito Norte de California . Oracle afirmó que Google era consciente de que había desarrollado Android sin una licencia de Java y había copiado sus API y que, por lo tanto, Google infringía los derechos de autor de Oracle. Oracle también citó siete patentes anteriores relacionadas con la tecnología Java creada por Sun y ahora propiedad de Oracle que Google debería haber conocido ya que habían contratado a antiguos desarrolladores de Sun que trabajaron en Java. Oracle solicitó tanto una indemnización monetaria como una orden judicial para impedir que Google utilizara los materiales supuestamente infractores. [26] [27]
El caso fue asignado al juez William Alsup , quien lo dividió en tres fases: derechos de autor, patentes y daños.
La fase de derechos de autor comenzó el 16 de abril de 2012 y consistió en varios reclamos distintos 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 derivaron del proyecto Apache Harmony. [11] Después de dos semanas de testimonios, el jurado concluyó el 7 de mayo de 2012 que Google había infringido los derechos de autor relacionados con el código, el SSO y la documentación de las API, así como con la función rangeCheck , pero no llegó a un acuerdo sobre si estas los usos estaban dentro del uso legítimo. El jurado también consideró 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 ello 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 no válidos. -infractora pero que Google había declarado que había copiado palabra por palabra; Alsup estuvo de acuerdo. Google solicitó un JMOL similar relacionado con rangeCheck , pero Alsup rechazó esta solicitud. [29]
La fase de patentes se inició el 7 de mayo de 2012, con el mismo jurado. [30] En el momento del juicio, el caso de patentes de Oracle comprendía reclamaciones de dos patentes, 6.061.520 (Método y sistema para realizar la inicialización estática), [31] (la patente '520) y RE38104 (Método y aparato para resolver referencias de datos en generados). código). [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 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 se habían infringido todas las reclamaciones 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 con respecto a la infracción de derechos de autor de las API, Alsup determinó que las API no tenían derechos de autor en primer lugar:
Siempre que el código específico utilizado para implementar un método sea diferente, cualquiera 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 las líneas de encabezado de declaración o método sean idénticas. [11]
Alsup estuvo de acuerdo con el jurado en que la función rangeCheck y ocho archivos de seguridad constituían una infracción de derechos de autor, pero la única reparación disponible eran daños legales hasta un máximo de 150.000 dólares estadounidenses [36] [37]
Como resultado de estos fallos y una estipulación, no hubo fase de daños y perjuicios del jurado. Las partes acordaron cero dólares en concepto de daños y perjuicios por la pequeña cantidad de código copiado hasta junio de 2012. [38] [39]
Poco después de la conclusión del caso del Tribunal de Distrito, ambas partes intentaron presentar JMOL 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 el reclamo de copia literal. Debido a que el caso involucraba reclamos relacionados con patentes, la apelación fue asignada automáticamente al Tribunal de Apelaciones del Circuito Federal de los Estados Unidos . [40] [41] La audiencia se celebró el 4 de diciembre de 2013, [42] [43] y la sentencia fue emitida 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 medio tangible de expresión" (p. 17). La historia legislativa explica que las obras literarias incluyen "programas de computadora en la medida en que incorporan la autoría en la expresión de las ideas originales por parte 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 fue "el primero en evaluar si la expresión es original del programador" (p. 24), algo que Google ya había reconocido (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 está protegida por derechos de autor. También falló a favor de Oracle respecto de la pequeña cantidad de copia literal, sosteniendo que no era de minimis . El caso fue devuelto al Tribunal de Distrito para un segundo juicio, para considerar si el uso de Google era aceptable de todos modos, según 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 Apelaciones se pronunciara. en 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]
Según lo ordenado por el Tribunal de Apelaciones, el 9 de mayo de 2016 comenzó un nuevo juicio en el tribunal de distrito sobre la cuestión de si las acciones de Google fueron un uso legítimo, dado el fallo previo de que las API estaban protegidas por derechos de autor. [48] [49] Los argumentos finales se completaron el 23 de mayo de 2016 y el jurado comenzó a deliberar. Oracle pedía una indemnización de hasta 9.000 millones de dólares. [50] [51] [52] [53] [54] [55] El 26 de mayo de 2016, el jurado determinó que Android no infringió los derechos de autor propiedad de Oracle porque su reimplementación de 37 API de Java estaba protegida por uso legítimo. . [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 escuchada por la Corte de Apelaciones del Circuito Federal de los Estados Unidos en 2017. El 27 de marzo de 2018, la Corte falló a favor de Oracle. [62] El fallo analizó los aspectos de una reclamación por "uso legítimo" que debían ser decididos por un juez y un jurado, respectivamente. Luego examinó las cuestiones de hecho a las que, era de suponer, había llegado el jurado, y sus implicaciones jurídicas. [62] Observó que en un caso "mixto" de hecho y de derecho, como el presente litigio, la función del jurado de primera instancia es decidir sobre los hechos. En su opinión, la jueza O'Malley citó el caso de la Corte Suprema Campbell contra Acuff-Rose Music, Inc. 510 U.S. 569 (1994), y señaló que:
[e]n verdad, en la literatura, en la ciencia y en el arte, hay y puede haber pocas cosas, si es que hay alguna, que en un sentido abstracto sean estrictamente nuevas y originales en todo momento. Todo libro de literatura, ciencia y arte toma prestado, y debe necesariamente tomar prestado y utilizar, mucho de lo que antes era bien conocido y utilizado. (citando a Emerson v. Davies, 8 F. Cas. 615, 619 (CCD Mass. 1845))
La función del Tribunal de Apelaciones es evaluar si un jurado razonable podría haber llegado a las conclusiones que llegó y si la decisión del juez podría ser correcta y razonable según la ley. 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 pregunta 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. son; y (3) evaluar si los hechos históricos encontrados satisfacen el criterio legal que rige la pregunta a responder" (Decisión p. 19). Salvo error claro, 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 de declaración de los 37 paquetes 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 API de Java. (Decisión p. 10)". También está establecido y Google reconoce que el software copiado es creativo y original.
El Tribunal concluyó que, como cuestión de derecho, el uso de Java por parte de Google no podría haber entrado dentro del uso legítimo, incluso si todas las cuestiones fácticas decididas por el jurado hubieran sido a favor de Google. El Tribunal de Apelaciones determinó que el uso por parte de Google de las declaraciones del código API 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 propósitos sin siquiera cambios o reescrituras mínimos. No fue mínimo, ya que se acordó que sólo 170 líneas de las 11.500 copiadas eran necesarias para los propósitos 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 ningún esfuerzo sustancial para utilizarlos con fines de interoperabilidad de terceros. (De hecho, descubrió que Google había intentado impedir la interoperabilidad con otros Java y Sun le había negado previamente una licencia por ese motivo. [13] ) Tampoco fue transformador en el sentido de una nueva plataforma, ya que otros teléfonos inteligentes Java eran anteriores. Androide. [62] Era plausible que el uso hubiera perjudicado a Sun/Oracle –quizás en gran medida si se creyera a Oracle– ya que, como resultado, los proveedores comenzaron a esperar que Oracle compitiera en precio con un derivado disponible gratuitamente de su propio lenguaje. y exigir descuentos muy elevados y condiciones contractuales no deseadas. [62] Por lo tanto, el uso por parte de Google del código Java y las API no cumplió con los cuatro criterios actualmente aceptados bajo los cuales el uso legítimo sería posible. [62]
En cambio, el Tribunal concluyó que el propósito de Google había sido aumentar el atractivo de su naciente plataforma Android para los desarrolladores existentes, que a menudo estaban familiarizados con Java, y evitar la "tediosa tarea" de reescribir el código (que podrían haber hecho) necesario para implementar el 170 líneas de detalles de API que efectivamente eran necesarias. Está bien establecido que "hacerlo fácil para uno mismo", señaló el tribunal, no entra dentro de los motivos válidos de uso legítimo. El Tribunal concluyó que "el hecho de que Android sea gratuito no hace que el uso de los paquetes API de Java por parte de Google no sea comercial". [63] Oráculo
ideó un plan de licencias para atraer programadores y al mismo tiempo comercializar la plataforma. En la parte relevante, Oracle cobra una tarifa de licencia a quienes desean utilizar 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. [64]
El propósito era comercial, los hechos históricos establecidos por el jurado no cumplían ninguno de los criterios de uso legítimo, [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 debería pagarle a Oracle. [63]
Google presentó una petición de auto de certiorari ante la Corte Suprema de Estados Unidos en enero de 2019 para impugnar los dos fallos que emitió el tribunal de apelaciones 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 entraba dentro del uso legítimo tal como se determinó en los juicios con jurado. [65] En órdenes emitidas en abril de 2019, el Tribunal 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 Computer & Communications Industry Association , la Internet Association , la Auto Care Association y un grupo colectivo de más de 150 académicos y profesionales de la informática también presentaron escritos apoyando la postura de Google, advirtiendo que una decisión a favor de Oracle dañaría la 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 preocupaciones. en torno a COVID-19 , y luego anunció que Google contra Oracle fue uno de varios casos del período 2019-20 que se pospusieron hasta la primera semana del período 2020-21. [72] [73] [74] Luego de la demora, el Tribunal solicitó 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 en el nivel de Distrito. [75]
Los argumentos orales se escucharon por teleconferencia debido a la actual pandemia de COVID-19 el 7 de octubre de 2020. [76] La jueza Ruth Bader Ginsburg había muerto el mes anterior y su reemplazo, la jueza Amy Coney Barrett , aún no había sido confirmada, por lo que Barrett no participó en el proceso. [77] Los observadores del tribunal descubrieron que, si bien los jueces parecían ponerse del lado de Oracle en los argumentos sobre 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 curiae que fallar a favor de Oracle podría alterar la industria del software. Varias preguntas se centraron en cómo las API caían dentro de la distinción idea-expresión del derecho de autor y si se aplicaría la doctrina de la fusión . También se consideró que el juez Gorsuch se centraba en gran medida en los argumentos de la Séptima Enmienda y en si el fallo del Circuito Federal de anular el veredicto del jurado del tribunal de primera instancia era adecuado. [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 legítimo, revocando el fallo del Tribunal Federal de Apelaciones del Circuito y remitiendo el caso para una audiencia adicional. . El juez Stephen Breyer redactó la opinión mayoritaria. La opinión de Breyer comenzó con la suposición de que las API pueden tener derechos de autor y, por lo tanto, procedió con una revisión de los cuatro factores que contribuyeron al uso legítimo: [79] [80]
Breyer determinó que el uso de las API por parte de Google había cumplido los cuatro factores y que Google utilizó "sólo 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 aquí 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 unió 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 distorsionante es una opinión que hace difícil imaginar cualquier circunstancia en la que declarar código permanecen protegidos por derechos de autor." [24] Thomas afirmó además que en su propio análisis de uso legítimo "el uso de ese código protegido por derechos de autor por parte de Google fue todo menos justo". [83]
Google contra Oracle fue un caso 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] Quienes se oponen 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 adquieran los derechos de software y archivos antiguos. demandas contra 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 paralizador en el desarrollo de software, ya que los titulares de derechos de autor utilizarían los derechos de autor de las API para evitar su uso en el desarrollo de alternativas interoperables mediante ingeniería inversa , como es 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ódigos 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 favoreciera 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....