Diez años después de que Oracle demandara por primera vez a Google por el código en la plataforma Android, los dos gigantes tecnológicos finalmente se enfrentan en la Corte Suprema. Desde entonces, ha habido tres juicios y dos apelaciones. Están en juego miles de millones de dólares; Es probable que se hayan gastado muchos millones en un desfile de litigantes experimentados, testigos expertos y exhibiciones de juicios extrañas destinadas a explicar la programación a jurados no técnicos. Todo esto puede estar llegando a un final anticlimático el miércoles por la mañana, con un argumento oral de la Corte Suprema por teleconferencia en medio de una pandemia.
Cuando Google desarrolló Android por primera vez, decidió hacer que la plataforma móvil fuera compatible con Java. En ese momento, las aplicaciones para el entorno iOS estaban escritas en Objective-C, un lenguaje que era similar al omnipresente C, pero por lo demás, prácticamente solo se usaba en el contexto del desarrollo de aplicaciones iOS. Apple tuvo una ventaja significativa en el sector móvil.
Google tenía como objetivo hacer que Android fuera competitivo al hacer que la plataforma fuera interoperable con Java, un lenguaje de programación popular con una sólida comunidad de desarrolladores. Para ello, la empresa volvió a implementar varias API de Java, incluidas las 37 que están en cuestión en la demanda. Para Oracle y Google, la demanda se trata de si Oracle, que posee Java Standard Edition, ahora tiene derecho a una parte de Android, por una suma de miles de millones de dólares. Para todos los demás, la demanda se trata de si la compatibilidad de idiomas equivale a una infracción de derechos de autor.
Por decir lo menos, era un mundo diferente cuando se presentó el caso por primera vez. Ambas empresas han cambiado de manos: la demanda comenzó cuando Larry Ellison todavía estaba al frente de Oracle y Eric Schmidt era el director ejecutivo de Google. Google ahora es una subsidiaria de Alphabet. Android está en la versión 11. Lo único que parece haberse mantenido igual es la popularidad de Java como lenguaje de programación.
Pero lejos de Silicon Valley, ha habido un cambio radical que abarca mucho más que $ 6 mil millones y el futuro de la ley de derechos de autor. Se han dejado vacantes tres escaños de la Corte Suprema desde la última vez que Google le pidió a la Corte Suprema que revisara su caso. En 2014, SCOTUS negó el certiorari y envió el caso de vuelta al tribunal de distrito de San Francisco para un nuevo juicio. Desde entonces, un juez se ha jubilado y dos han fallecido; más recientemente, la juez Ruth Bader Ginsburg.
La parte absolutamente menos importante del legado de Ginsburg es que fue el voto más confiable en los casos de leyes de derechos de autor, tendiendo a votar a favor de los titulares de derechos. Su pérdida también significa que Google v. Oracle está siendo escuchado por ocho jueces y, por lo tanto, es propenso a un tribunal dividido. (En el caso de copyright de software de 1996 Lotus v. Borland , un tribunal de ocho jueces se dividió en partes iguales y no pudo sentar un precedente nacional).
Cuando Google v. Oracle comenzó en 2010, involucró siete patentes, así como un reclamo de derechos de autor; en 2012, el caso se había reducido a apenas 37 API de Java, compuestas por unas 11.500 líneas de código. (Las diversas versiones de Android van desde 12 a 14 mil millones de líneas de código). Las 11.500 líneas de código en cuestión se escribieron en una "sala limpia", un proyecto aislado del código existente que estaban haciendo ingeniería inversa. Esta hazaña de ingeniería se hizo necesaria cuando las negociaciones entre Google y Sun Microsystems, que era propietario de la plataforma Java, fracasaron. Oracle adquirió Sun a principios de 2010; en agosto, había presentado una demanda contra Google.
Una interfaz de programación de aplicaciones (API) en este contexto es una colección de interacciones bien definidas en la programación de software. Es una forma abreviada de acceder rápidamente a servicios, bibliotecas y otras funciones. Una API puede condensar código de uso común o detallado, lo que permite a los programadores construir sin tener que reinventar la rueda.
Una API no es exactamente un diccionario, pero está lo suficientemente cerca de uno que Oracle v. Google plantea un gran problema. Técnicamente , puede programar en Java sin utilizar los 37 paquetes de API de Java en cuestión. Pero probablemente no escribiría nada útil, ya que esas API incluyen java.lang y java.util, paquetes básicos que ofrecen funciones como hacer matemáticas o representar fechas y horas. Técnicamente, también puedo escribir este artículo sin metáforas o símiles, pero no es algo que me gustaría hacer o que nadie quisiera leer.
Para ser claros, las 37 API de Java se volvieron a implementar en una sala limpia. Oracle no afirma que sean exactamente iguales, sino que la "estructura, secuencia y organización" de las API son tan similares que violan la ley de derechos de autor. Con esto, significa que los paquetes, clases y métodos en estas API tienen el mismo nombre. Una línea de código escrita para ejecutarse en Java Standard Edition no necesariamente se ejecutará en Android, pero se acercará mucho más de lo que hubiera sido de otra manera.
La primera ejecución de la demanda resultó en un juicio bifurcado en 2012: un juicio para las reclamaciones de patentes y un segundo juicio solo para las reclamaciones de derechos de autor. En el juicio de patentes, el jurado dictaminó que Google no había infringido ninguna patente. En el juicio de derechos de autor, dos puntos legales separados estaban en discusión: primero, si el código declarante y la “estructura, secuencia y organización” de las API eran susceptibles de derechos de autor; y segundo, si el uso de Google fue un uso legítimo. El juez se pronunció sobre la cuestión de los derechos de autor y envió la cuestión del uso justo para que la evaluara el jurado.
El jurado se inclinó por el uso legítimo. Pero el juez, que casualmente escribió código como un pasatiempo , dictaminó que el código de declaración y el SSO de las API no estaban cubiertos por derechos de autor después de todo. La Ley de derechos de autor no se aplica a ninguna “idea, procedimiento, proceso, sistema, método de operación” y la forma en que los paquetes, clases y métodos fueron nombrados y ordenados fue demasiado funcional para ser considerada digna de derechos de autor.
Fue esta decisión específica la que fue anulada por el Circuito Federal en 2014. Debido a que el primer jurado había estado pendiente del uso legítimo, se tuvo que convocar un jurado completamente nuevo para otro juicio sobre el uso legítimo en 2016. El jurado se puso del lado de Google.
Pero en 2018, el Circuito Federal, el mismo tribunal de apelaciones que en 2014 había devuelto el caso al jurado, dictaminó que el veredicto del jurado debía anularse a favor de Oracle, porque las pruebas presentadas en el juicio indicaban claramente que no había justicia. la determinación de uso podría alcanzarse y, por lo tanto, no debería haber acudido a un jurado en primer lugar.
Dejar a un lado el veredicto del jurado es Big Judge Energy de una manera que seguramente será controvertida para la Corte Suprema, y es probable que el argumento oral del miércoles incluya una gran cantidad de discusión sobre el papel del juez contra el jurado en un caso de derechos de autor. La cuestión de quién decide el uso legítimo y cuándo es algo que se puede extrapolar a muchos casos legales diferentes (que a SCOTUS le encanta) y tampoco tiene nada que ver con las matemáticas (que a SCOTUS no le encanta).
Desafortunadamente, el verdadero corazón del caso radica en la parte con todas las matemáticas y demás. La decisión de la Corte Suprema en Google contra Oracle podría tener enormes ramificaciones para la industria del software, sobre todo porque la Corte Suprema puede estar revisando el tema de los derechos de autor: la cuestión de si el código declarante y la estructura, secuencia y organización de las API de Java son cubierto por la ley de derechos de autor, que no ha estado en juego desde 2014.
Este enfrentamiento de rencor de una década entre Google y Oracle no es del todo racional. La reimplementación de las API de Java por parte de Google es parte de una larga tradición de iteración que hasta ahora se daba por sentado. Productos como el propio MySQL de Oracle se crearon como iteraciones del SQL de IBM.
Esto no quiere decir que copiar y pegar sea el corazón de Silicon Valley. Pero hay un punto en el que desea alentar que las cosas se vean iguales, en lugar de ser diferentes por el bien de la diferencia. En pocas palabras: codificar es el proceso de hablar con la máquina. Pero muy pocas personas que desarrollan software en estos tiempos realmente hablan directamente con la máquina. El software existe en capas sobre capas iterativas, un juego de susurros que finalmente llega al metal desnudo de la computadora. Los nuevos lenguajes se derivan de los antiguos; las nuevas bibliotecas se basan en las existentes; las dependencias se apilan unas sobre otras como un juego de Jenga que está a punto de terminar en cualquier momento. Y Google v. Oracle es un caso que está sucediendo en uno de los niveles más bajos de un juego en curso de Jenga.
Estamos a punto de averiguar si la Corte Suprema lo sabe.