Diez años después de que Oracle demandara por primera vez a Google por el código de la plataforma Android, los dos gigantes tecnológicos se enfrentan por fin en el Tribunal Supremo. Desde entonces, ha habido tres juicios y dos apelaciones. Hay miles de millones de dólares en juego; es probable que se hayan gastado muchos millones en un desfile de experimentados litigantes, testigos expertos y extrañas pruebas de juicio destinadas a explicar la programación a jurados no técnicos. Todo esto puede llegar a un final anticlimático el miércoles por la mañana, con un argumento oral del Tribunal Supremo por teleconferencia en medio de una pandemia.
Cuando Google desarrolló por primera vez Android, decidió hacer la plataforma móvil compatible con Java. Por aquel entonces, las aplicaciones para el entorno iOS se escribían en Objective-C, un lenguaje similar al omnipresente C pero que, por lo demás, sólo se utilizaba en el contexto del desarrollo de aplicaciones para iOS. Apple llevaba una importante ventaja en el ámbito de los móviles.
Google pretendía hacer que Android fuera competitivo haciendo que la plataforma fuera interoperable con Java, un popular lenguaje de programación con una sólida comunidad de desarrolladores. Para ello, la compañía reimplementó varias API de Java, incluidas las 37 que están en cuestión en la demanda. Para Oracle y Google, el pleito consiste en saber si Oracle, propietaria de Java Standard Edition, tiene ahora derecho a una parte de Android, por valor de miles de millones de dólares. Para todos los demás, el pleito es sobre si la compatibilidad de lenguajes equivale a una infracción de los derechos de autor.
Para decir lo menos, era un mundo diferente cuando se presentó el caso por primera vez. Ambas empresas han cambiado de manos: el pleito comenzó cuando Larry Ellison aún estaba al frente de Oracle y Eric Schmidt era el consejero delegado de Google. Ahora Google es una filial de Alphabet. Android está en la versión 11. Lo único que parece haber permanecido igual es la popularidad de Java como lenguaje de programación.
Pero lejos de Silicon Valley, se ha producido un cambio radical que abarca mucho más que unos simples 6.000 millones de dólares y el futuro de la ley de derechos de autor. Tres puestos del Tribunal Supremo han quedado vacantes desde la última vez que Google pidió al alto tribunal que revisara su caso. En 2014, el SCOTUS denegó el certiorari, devolviendo el caso al tribunal de distrito de San Francisco para un nuevo juicio. Desde entonces, un juez se ha jubilado y dos han fallecido, la más reciente, la jueza Ruth Bader Ginsburg.
La parte menos importante del legado de Ginsburg es que era el voto más fiable en los casos de la ley de derechos de autor, tendiendo a votar a favor de los titulares de derechos. Su pérdida también significa que el caso Google v. Oracle será juzgado por ocho jueces y, por lo tanto, es probable que el tribunal esté dividido. (En el caso de derechos de autor de software de 1996, Lotus contra Borland, un tribunal de ocho jueces se dividió en partes iguales y no pudo sentar un precedente nacional).
Cuando Google contra Oracle comenzó en 2010, incluía siete patentes, así como una reclamación de derechos de autor; en 2012, el caso se había reducido a sólo 37 API de Java, compuestas por unas 11.500 líneas de código. (Las 11.500 líneas de código en cuestión se escribieron en una «sala blanca», un proyecto aislado del código existente que estaba siendo objeto de ingeniería inversa. Esta hazaña de ingeniería fue necesaria cuando fracasaron las negociaciones entre Google y Sun Microsystems, propietaria de la plataforma Java. Oracle adquirió Sun a principios de 2010; en agosto, ya 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 verboso, lo que permite a los programadores construir sin tener que reinventar la rueda.
Una API no es exactamente un diccionario, pero se acerca lo suficiente a uno como para que el caso Oracle vs. Google plantee un gran problema. Técnicamente, se puede programar en Java sin utilizar los 37 paquetes de la API de Java en cuestión. Pero probablemente no estarías escribiendo nada útil, ya que esas APIs incluyen java.lang y java.util, paquetes básicos que ofrecen funciones como hacer matemáticas o representar fechas y horas. También puedo escribir técnicamente este artículo sin metáforas ni símiles, pero no es algo que quisiera hacer, ni que nadie quisiera leer.
Para ser claros, las 37 APIs de Java fueron reimplementadas en una sala limpia. Oracle no afirma que sean literalmente iguales, sino que la «estructura, secuencia y organización» de las APIs son tan similares que violan la ley de derechos de autor. Con esto quiere decir que los paquetes, las clases y los métodos de estas API tienen el mismo nombre. Una línea de código escrita para ejecutarse en Java Standard Edition no se ejecutará necesariamente en Android, pero se acercará mucho más de lo que lo habría hecho de otro modo.
El primer intento de demanda dio lugar a 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 por los derechos de autor, se discutieron dos puntos legales distintos: en primer lugar, si el código de declaración y la «estructura, secuencia y organización» de las API eran susceptibles de ser protegidos por derechos de autor; y en segundo lugar, si el uso de Google era un uso justo. El juez se pronunció sobre la cuestión de la propiedad intelectual, y envió la cuestión del uso legítimo para que la evaluara el jurado.
El jurado falló sobre el uso legítimo. Pero el juez -que casualmente escribía código como hobby- dictaminó que el código declarante y el SSO de las APIs no estaban cubiertos por los 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, las clases y los métodos fueron nombrados y ordenados era demasiado funcional para ser considerado digno de derechos de autor.
Fue este fallo específico el que fue anulado por el Circuito Federal en 2014. Debido a que el primer jurado había fallado sobre el uso justo, se tuvo que convocar un jurado completamente nuevo para otro juicio sobre el uso justo 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 tenía que ser anulado a favor de Oracle, porque las pruebas presentadas en el juicio indicaban claramente que no se podía llegar a una determinación de uso justo, y por lo tanto no debería haber ido a un jurado en primer lugar.
La anulación de un veredicto del jurado es una decisión del Gran Juez Energy que seguramente resultará controvertida para el Tribunal Supremo, y es probable que el argumento oral del miércoles incluya un buen debate sobre el papel del juez frente al jurado en un caso de derechos de autor. La cuestión de quién decide el uso justo, y cuándo, es algo que se puede extrapolar a un montón de casos legales diferentes (que el SCOTUS ama) y también no tiene nada que ver con las matemáticas (que el SCOTUS no ama).
Desgraciadamente, el verdadero corazón del caso se encuentra en la parte con todas las matemáticas y demás. La decisión del Tribunal Supremo en el caso Google vs. Oracle podría tener enormes ramificaciones para la industria del software, sobre todo porque el Tribunal Supremo podría volver a examinar la cuestión de la patentabilidad -la cuestión de si el código declarante y la estructura, la secuencia y la organización de las API de Java están cubiertos por la ley de derechos de autor en absoluto- que no ha estado en juego desde 2014.
Este enfrentamiento de una década entre Google y Oracle no es del todo racional. La reimplementación de las APIs de Java por parte de Google forma parte de una larga tradición de iteración que hasta ahora se daba por supuesta. Productos como el propio MySQL de Oracle se crearon como iteraciones del SQL de IBM.
Esto no quiere decir que el copy-pasting sea el corazón de Silicon Valley. Pero hay un punto en el que se quiere fomentar que las cosas parezcan iguales, en lugar de que sean diferentes por el hecho de serlo. En pocas palabras: la codificación es el proceso de hablar con la máquina. Pero muy pocas personas que desarrollan software en esta época hablan directamente con la máquina. El software existe en capas sobre capas iterativas, un juego de susurros que finalmente llega al metal desnudo del ordenador. Los nuevos lenguajes se derivan de los antiguos; las nuevas bibliotecas se construyen sobre 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 contra Oracle es un caso que está ocurriendo en uno de los niveles más bajos de un juego de Jenga en curso.
Estamos a punto de averiguar si el Tribunal Supremo lo sabe.
Corrección: Una versión anterior del artículo afirmaba erróneamente que la base de código de Android era de miles de millones de líneas de código. Se trata de millones. Lamentamos el error.