En el que debe ser el caso judicial más importante en materia tecnológica en muchos años, la Corte Suprema de Estados Unidos sostuvo (por 6–2) que Google no cometió ninguna infracción de derecho de autor al copiar pedazos de la API Sun Java de Oracle para construir Android. En particular, sostuvo que ese tipo de copia o reproducción es un ejemplo de fair use en el marco de la legislación estadounidense, por tanto no es una infracción.

El fallo y sus alcances -y también lo que no quiso decir la Corte- van a ser probablemente objetos de largos análisis y artículos muchísimo más sofisticados y largos que este. Pero como también es una materia extremadamente de nicho, me voy a detener en dos asuntos fundamentales: qué es una API y por qué el fallo es importante para la industria de software.

Qué diablos es una API

Aunque parezca increíble, buena parte de la discusión respecto de este caso se concentró en la naturaleza jurídica de estas “application programming interfaces” o APIs. Si bien son en sentido estricto código, una API es más bien un grupo de especificaciones que permite el acceso a datos, una aplicación o un servicio. Una API es un intermediario, si se quiere. Una interfase que conecta a otra cosa[1].

Considere esta exhaustiva analogía –aun cuando sea un poco exagerada- que ilustra cómo es usar una API para un programador. Imagine que puede, gracias a un teclado, darle instrucciones a un robot para que vaya a un estante, abra un determinado cajón y saque una específica receta guardada. Con la receta en la mano, el robot va a su cocina y se la entrega a un cocinero para que prepare el plato. Este ejemplo es exactamente como funciona el sistema organizacional sobre el que funciona una API. A través de un comando simple, el robot localiza la receta exacta y se la entrega al cocinero. Del mismo modo, escribir una llamada de método («method call») le solicita a la API que encuentre el código de implementación y se lo entrega a su computador. Adicionalmente, y no menos importante, elegir el plato que usted quiere para la cena, usted no necesita saber el contenido de la receta, tal como el programador usando una API no necesita aprender cómo se implementa el código («implementing code»). En ambos casos, aprender el comando es suficiente.

El juez Stephen Breyer (quien redactó el fallo) lo explica con peras y manzanas (aunque la traducción es mía)

Esta técnica de usar APIs ha sido usada por décadas, dado que permite a desarrolladores poder escribir programas que usan funcionalidades de otro sin necesidad de saber cómo funcionan internamente. Como se trata de un set de especificaciones documentadas, los desarrolladores no tienen que aprender a escribir lenguajes diferentes cada vez que sus programas requieren interoperar con otros. Simplemente siguen esas especificaciones y pueden interoperar.

Pero en el marco del debate de este caso (que duró más de una década) abogados de Oracle intentaron esgrimir que, en realidad, una API es lo mismo que el software o aplicación al que entrega acceso. Mientras Google argumentaba que «copiar APIs» era una práctica extendida y común de la industria, Oracle sugería que se trataba de una infracción a sus derechos de autor (en su calidad de titular de los derechos de Java). Por tanto, Google debía pasar por caja.

Por otro lado, la abogada de Oracle Annette Hurst (hasta entonces una reputadísima abogada de propiedad intelectual en Estados Unidos), públicamente defendió la idea de la equivalencia entre API y programa, incluso señalando que la API de Java es “ejecutable”, que es más o menos equivalente a pensar que es lo mismo el menú de un restaurant que el plato de comida caliente que te estás comiendo. Esto, que puede ser un tecnicismo fino, da cuenta de una confusión total respecto del asunto.

Por qué este fallo es importante

Como decía, acceso abierto a APIs es esencial para desarrolladores de software actuales. Se me hace muy difícil pensar en un modelo de desarrollo de software que interopere, que pueda funcionar en distintas plataformas, por ejemplo, sin el uso masivo de APIs. Si por cada vez que un desarrollador quiera implementar una operación interoperable con otro software debiese aprender el lenguaje de cada uno de aquellos con quienes necesita interoperar, no solo crearía barreras brutales para la innovación, sino que además haría excesivamente costoso poder desarrollar programas que puedan conversar entre sí. El efecto más obvio, sería la concentración aun mayor de un mercado en pocas manos.

De alguna forma, este fallo es un suspiro para una industria que navega siempre en aguas turbulentas cuando se trata del marco legal aplicable. Para este marco legal, hay pocas diferencias normativas entre un programa computacional y una poesía.

Como suele suceder con los fallos de la Corte Suprema estadounidense, no resolvieron todos los asuntos. Por ejemplo, una de las preguntas principales, que fueron objeto de casi todos los amicus presentados a favor de Google (Mozilla, EFF, o el de Public Knowledge), era la definición si es que estas APIs están o no sujetas a derecho de autor. Si se trata de obras protegibles. El fallo no responde esta pregunta, sino que opta por la opción de determinar que el uso de ellas califica como fair use de acuerdo a la doctrina tradicional. No es el mejor escenario, pero el casi mejor.

Por último, es interesante que el fallo haya destacado la importancia del interés público involucrado cuando se trata de permitir que desarrolladores puedan usar estas tecnologías para desarrollar soluciones interoperables. Es llamativo que sea la primera decisión donde la Corte haga referencia al fair use desde un caso de parodias en 1994 (Campbell v. Acuff-Rose Music). De hecho, dada la naturaleza de la idea de fair use, resulta especialmente interesante que la Corte Suprema decida explorar estas áreas para incorporar usos autorizados en el marco del software ampliando, de alguna forma, su alcance. Por ejemplo, está por ver si esta mirada respecto del fair use abre un poco la nebulosa legal en que están archivistas de software antiguo o hasta creadores de fan fiction, como la sugerido Kendra Albert.