El caso Oracle America v. Google: ¿Son patentables las interfaces de software?

Por: Lina María Díaz - Abogada, Asistente de Investigación

Oracle América (Oracle en adelante), empresa dedicada a la elaboración de software desde 1977, demandó a Google por la infracción de 37 paquetes de códigos fuente para computadores, escritos en el lenguaje de programación de Java, el cual Oracle licencia a otras empresas o programadores para que escriban y creen aplicaciones (APPS) compatibles con el sistema Java. Según Oracle, la infracción se debió a que en la configuración del sistema operativo Android, empleado en los dispositivos móviles de Google, se copiaron fragmentos de los códigos fuente de Java.

 Martes, 24 de Junio de 2014 

Palabras clave: interfaz de software, AIPs, SSO, APPS, Merger Doctrine, interoperabilidad.

 

Oracle América (Oracle en adelante), empresa dedicada a la elaboración de software desde 1977, demandó a Google por la infracción de 37 paquetes de códigos fuente para computadores, escritos en el lenguaje de programación de Java, el cual Oracle licencia a otras empresas o programadores para que escriban y creen aplicaciones (APPS) compatibles con el sistema Java. Según Oracle, la infracción se debió a que en la configuración del sistema operativo Android, empleado en los dispositivos móviles de Google, se copiaron fragmentos de los códigos fuente de Java.

 

1.     Algunos conceptos técnicos:

Con el ánimo de facilitar la comprensión del caso, a continuación se explican algunos conceptos técnicos de informática referentes las creaciones y de las obras que fueron objeto de discusión en el mismo:

v  API: Las Application Programming Interfaces o una interfaz de programación es un conjunto de funciones e instrucciones que permiten la interoperabilidad entre diferentes softwares o aplicaciones, ya que para que estos funcionen entre sí y con el dispositivo o hardware deben estar escritos en el mismo lenguaje de programación. La profesora Pamela Samuelson, del centro de Tecnología y Derecho de la Universidad  Berkley para explicar en qué consisten las interfaces de programación señala: “Para que un aparato inter-opere con la red eléctrica, el desarrollador debe configurar el enchufe para que se ajuste perfectamente a la toma de corriente estándar que se emplea para conectar los aparatos a la red[1], lo mismo sucede con las aplicaciones y los software, para poder funcionar necesitan ajustarse a aquellos diseñados con anterioridad. Algunos ejemplos de APIs son Microsoft WMI, Microsoft Win32 API, Microsoft Framework .NET, OpenGL, Java EE etc.

v  APPS: Las aplicación informática (Applications) son un conjunto de programas –software- que debe ejecutar el sistema operativo para que el dispositivo electrónico funcione de la forma en que el usuario espera, realizando una o varias tareas.  Son ejemplos de aplicaciones los navegadores de internet como Google, o de comunicación y envío de mensajes como Whatsapp, etc.

v  Código fuente: Es una serie de instrucciones escritas por un programador utilizando un lenguaje programación para expresar los procesos lógicos y físicos que deberá realizar el hardware para ejecutar tareas, éste es una creación intelectual del programador.

v  Código objeto: Es la traducción que realiza la máquina o hardware del código fuente para transformarlo en un lenguaje que él pueda comprender, el bytecode, escrito en sistema binario y que indica al Hardware las instrucciones y pasos que debe seguir para desarrollar una tarea. Este lenguaje no es fácilmente comprensible por el hombre y es justamente en esta forma en que se distribuye la mayoría de software, a los cuales, pese a ser un trabajo arduo, es posible aplicarles ingeniería a la inversa para obtener el código fuente que subyace en ellos.

 v  Lenguaje de programación: Es un lenguaje utilizado para crear programas o software, compuesto por caracteres, reglas de sintaxis (estructura) y de semántica (significado) que permitan al hardware interpretar y comprender la información contenida en el código fuente, ya que los hardware funcionan con código binario[2]. Un ejemplo de lenguaje de programación es justamente Javascript, que al ser instalado permite mejoras en la interfaz del usuario y el funcionamiento de páginas web.

v  Sistema operativo: Los operating system programs se encargan de las funciones internas del hardware, determinando qué funciones o programas habrá de ejecutar este antes que otras, estableciendo un orden entre ellas, de forma que el uso del hardware resulte más eficiente y atienda mejor las necesidades y requerimientos del usuario. Es decir, los sistemas operativos “manejan las funciones internas del computador, actúan como un cerebro y permiten que el computador lleve a cabo determinadas funciones requeridas.”[3] Como ejemplo de sistema operativo se puede citar a Android.

v  Software: Es un término genérico que designa cualquier tipo de programa que es ejecutado por el hardware o dispositivo electrónico. Los software pueden ser de dos tipos; los aplicativos en los que el usuario realiza una tarea en particular, o también pueden ser sistémicos, que son aquellos que soportan y permiten el funcionamiento de las aplicaciones. Estos serán creados por los programadores empleando un lenguaje de programación para crear un código fuente que las máquinas transformen en código objeto.

2.     Los hechos más relevantes del caso

En el caso que se analiza, Oracle escribió una serie de códigos fuente, consistentes en interfaces de programación, con el propósito de que otros programadores escribieran sus propios códigos partiendo de aquellas interfaces, ahorrando una parte considerable del proceso de programación. Del total de 37 códigos de Oracle, las partes coincidieron en que tres de ellos (java.lang, java.io y java.util) eran programas núcleo, es decir que los programadores que decidiesen emplear Java como lenguaje de programación se verían conminados a emplear esos tres códigos para poder crear sus programas[4].

El software sistémico Android fue elaborado específicamente para dispositivos móviles, y compite en este mercado con el software de Oracle, Java Micro Edition. Las partes, Oracle y Google, negociaron durante varios meses una licencia que permitiera a Google emplear los códigos Java en sus dispositivos. Sin embargo, la negativa de Google de hacer sus programas interoperables con otros códigos Java impidió la celebración del acuerdo. No obstante lo cual, Google decidió emplear el lenguaje operativo Java. Además, para que los usuarios de los dispositivos de Google encontraran en ellos programas y aplicaciones equivalentes a las de Oracle, Google copio la secuencia, estructura y organización SSO de los 37 códigos fuente de Oracle.

Sin embargo, pese a haber copiado parte de los códigos y haber empleado el lenguaje Java, el sistema operativo Android, y todas las aplicaciones creadas para el mismo, fueron diseñadas por Google de forma que no fuesen compatibles con el sistema Java, es decir, las aplicaciones que se escriban o programen para uno no podrán ser utilizadas en el otro.

3.     El problema jurídico

En la apelación presentada por ambas partes frente a la decisión de la Corte del Distrito de  California del Norte, la Corte de Apelaciones del Circuito Federal (CACF en adelante) debió decidir si las interfaces de Oracle son o no susceptibles de protección bajo el copyright. Este, al igual que el régimen de Derechos de Autor,  no protege las ideas sino la forma en que estas son expresadas, pero además, gracias al Doctrine Merger, el copyright no protegerá aquellas ideas de tal forma fusionadas con su forma de expresión, que no puedan expresarse de otra manera. En estos casos la obra será “uncopyrightable”[5]. Con esta doctrina se busca evitar que,  por medio de las normas del copyright, se conceda el monopolio sobre una idea.

En este orden de ideas, la cuestión planteada a la CACF consistía en determinar si las interfaces de programación (APIs) de Oracle son una idea que se encuentra unida de forma tan inescindible a su forma de expresión –código fuente- que no pueden ser protegibles por el copyright.

4.     La decisión de la CACF

La CACF inició sus consideraciones resaltando que el Copyright protegerá aquellas obras originales, que tengan un mínimo de creatividad y que serán protegidas las formas de expresión y no las ideas en sí mismas consideradas. Esta dicotomía entre las ideas y su forma de expresión está consagrada en la § 102 (b) del Copyright Act[6] y es explicada en los siguientes términos: “En ningún caso la protección del Copyright sobre una obra original de un autor se extiende a la idea, el procedimiento, proceso, sistema, método de operación, concepto, principio o descubrimiento, independientemente de la forma en la que se describa, explica, ilustre, o se haya embebido en este tipo de trabajo.” [7]

Para aplicar este principio al software se han creado dos reglas. La primera indica que la protección del copyright se extiende solamente a la expresión y no a las ideas, sistemas o procesos contenidos en el software; y la segunda, que los elementos esenciales de un software, indispensables para su funcionamiento no son protegibles, son uncopyrightable. Asimismo, los elementos protegibles pueden ser literales o no literales, dentro de los primeros se encuentran en código fuente y el código objeto, mientras que los no literales serán la estructura, secuencia y organización (SSO) del software y la interfaz de usuario.

Debido a que los software pos sí mismos son obras que integran una funcionalidad, a diferencia de otras obras protegidas por Copyright, puede resultar difícil decidir si un elemento literal o no literal de un software es protegible, ya que la idea o función del software es fácilmente confundible con su forma de expresión o exteriorización. A fin de realizar un análisis objetivo y evitar decisiones contradictorias ante casos similares, las cortes de los diferentes circuitos de Estados Unidos elaboraron un test de tres pasos – “abstraction, filtration, comparison”-  que les permite determinar si el elemento no literal de un software es o no protegible, y también si un programa ha sido infringido o copiado.

El paso de la abstracción implica dividir el software en todas sus partes, el segundo, en extraer del análisis aquellas partes no protegibles, ya sea porque son ideas, porque no son originales, o porque son ideas fusionadas con su forma de expresión –merger doctrine-. El tercer paso, exige comparar las partes protegibles del software, restantes del segundo paso, y compararlas con el software infractor[8].

Ahora bien, al abordar el caso concreto, con respecto a la Merger doctrine, la CAFC indicó que “cuando una parte especifica de un software, (…), es la única forma de indicar al hardware que realice una tarea, su uso por terceros no es considerado como una infracción”. De esta manera, el quid para determinar si un software se fusiona o no con la idea o función que incorpora radica en determinar si el código fuente se puede escribir de otra forma e impartir las mismas instrucciones al hardware.

Las diferentes posturas entre la corte de primera y la de segunda instancia respecto al momento en que debe analizarse si existen o no varias formas de escribir el código fuente, esto es, al momento de crearlo o posteriormente al copiarlo, fue lo que inclinó la balanza a favor de Oracle.

En efecto, la Corte Distrital evaluó las opciones al alcance de los programadores de Google para escribir los APIs. Por el contrario, a juicio de la CAFC, el análisis correcto debe realizarse sobre las opciones de escritura con que contaba el programador del software para escribirlo, en este caso Oracle. Esto, por cuanto la susceptibilidad de una obra de ser protegida deber ser determinada al momento de su creación, y no cuando es copiada ilícitamente[9].

Así, debido a que Oracle al momento de crear sus APIs contaba con una infinidad de opciones, y que las partes copiadas por Google, conocidas como Headers y que sirven para determinar variables y funciones del software, pudieron haber sido nombradas y escritas de cualquier forma, sin condicionamiento alguno de factores externos y conservando su funcionalidad, la CACF concluyó que los APIs eran protegibles por el Copyright, sin que la merger doctrine encontrara cabida en el presente caso.

Con respecto a la secuencia, estructura y organización (SSO) de los APIs, elemento no literal de los software pero también susceptible de programación, Oracle solicitó a la CACF declarar que la forma particular en que organizó los 37 paquetes de códigos fuente debe ser amparada por el Copyright, y que no se permita a Google emplear tal estructura. Considerando que la Corte Distrital encontró que la SSO de los APIs era original y creativa, y que el código fuente de los mismos puede ser escrito en una gran cantidad de formas conservando su funcionalidad, la CAFC accedió a las pretensiones de Oracle.

Tratamiento totalmente contrario recibió la excepción planteada por Google, consistente en que los APIs no deberían ser protegidos ante la necesidad de conservar y permitir la interoperabilidad del software. Efectivamente, la CACF consideró que este asunto no era relevante a la hora de determinar si una obra está o no amparada por el Copyright, sino para evaluar si el uso de la obra protegida puede ser considerado como un uso justo y permitido por la ley.

A juicio de la CACF, el hecho de que un programador desee crear un programa o software que sea compatible y que funcione con otros ya existentes, carece de relevancia a la hora de determinar si estos están amparados por el Copyright o no. De esta forma señala la CACF que la evaluación de la protección de una obra o, mejor, de un software se debe enfocar en estudiar si al momento de su creación existían o no otros métodos para llegar al mismo resultado, mientras que el asunto de la interoperabilidad o compatibilidad de entre dos software radica en considerar si la creación de un software es dictada por la necesidad de asegurar que el programa va a funcionar con los que ya existen[10].

La CACF resaltó además, que la decisión de lograr la compatibilidad de dos programas es comercial y competitiva, y nada tiene que ver con el hecho de que una idea se fusione con su forma de expresión, impidiendo su protección con el copyright.  En el caso concreto, si el software de Google es o no compatible con el de Oracle, nada tiene que ver con la protección o no de los  37 APIs de Oracle.

En suma, la CACF concluyó que el SSO de los 37 paquetes APIs de Oracle y sus respectivas SSO son protegibles –copyrightable-, debido a que al momento de su creación existían varios métodos para escribir el código fuente, y que la necesidad posterior de escribir programas funcionalmente compatibles con los APIs, nada tiene que ver con la protección de aquellos. Sin embargo, la excepción de uso justo planteada por Google para justificar el uso de los APIs, es un asunto que deberá atender la Corte Distrital según la evidencia que alleguen las partes.

La decisión de la CACF ha despertado gran interés y generado abundante controversia. Por ejemplo, la profesora Pamela Samuelson de la Universidad Berkley, sostiene que uno de los principales errores en el caso Oracle v Google es sostener que la merger doctrine, en lo relacionado con programas, solo será aplicable en caso de que el programador de una interfaz o API tenga solo una opción para diseñarla y llegar al mismo resultado funcional. Debido a que “no importa que tanta creatividad se haya invertido en el diseño de un programa de interfaz existente, y no importa con qué tantas opciones haya contado el programador cuando creó su diseño, una vez que una interfaz es creada, se convierte en un límite para el diseño de los programas que sigan diseñados para interoperar con él.”[11]

 

También sostiene la profesora Samuelson que la CAFC erró al no acoger la excepción de uso justo de Google, ya que tal postura es equivalente a conceder a Oracle un monopolio sobre los aspectos funcionales de las interfaces, lo cual está expresamente prohibido bajo la §102 (b) del Copyright Act, y a que tal protección solo puede ser concedida con una patente de cumplir con los requisitos impuestos por la ley de patentes[12].

Finalmente, recogiendo lo dicho hasta el momento y teniendo en la cuenta la reciente decisión de Corte Suprema de los Estados Unidos en el caso Alice Corporation Pty. Ltd v. CLS Bank International et al[13], en el cual se negó la patentabilidad de un software bancario[14] por considerar que la patente reivindicaba una idea abstracta y no una invención, lo cierto es que aún los programas y software no encuentran en los derechos de autor ni en las patentes un mecanismo de protección que se ajuste a sus características intrínsecas de funcionalidad y necesidad de compatibilidad.

[1] Traducción del  siguiente texto: “to make an appliance that can interoperate with the electrical grid, its developer must configure the plug so that it fits neatly into de standard wall socket that has come to be used to connect appliances to the grid”. SAMUELSON. Pamela. The strange odyssey of software interfaces and intellectual property law. Berkley Center of Law & Technology. University of California. Berkley. Paper 50. 2008. p 1.

[2]  Lenguajes de programación. Informática IV. Universidad Nacional Autónoma de México. Disponible en: http://fcasua.contad.unam.mx/apuntes/interiores/docs/98/4/informatica_4.pdf

[3] RENGIFO. Ernesto. El software y su protección Jurídica.  Derecho Penal y Criminología, Revista del Instituto de Ciencias Penales y Criminológicas, Universidad Externado de Colombia, vol. XV, número 50, mayo/agosto 1993, p 344.

[4] Vale aclarar que Oracle comercializa aquellas interfaces por medio de tres tipos de licencias. Las licencias “open source” en la cual los usuarios o programadores acceden a los códigos con la única condición de publicar las mejoras que realicen a los mismos. Las Specification license, que permiten a los usuarios el uso de los códigos Java bajo ciertas restricciones, y las Commercial Licenses que permiten el uso a cambio de contraprestaciones económicas. Para poder acceder a las dos últimas licencias, los programas que se creen a partir de los códigos Java deben pasar pruebas de compatibilidad para conservar el lema de Java “write once, run anywhere”.

[5] Cfr. HEBL. Andrew B. A heavy burden: proper application of copyright’s merger and scenes a faire doctrines. WAKE FOREST Intellectual Property Law Journal. vol 8. 2007-2008. p 138 – 141.

[6]  “In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.”

[7] Traducción del siguiente texto: “In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation,  concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.”  Court of Appeal of the Federal Circuit. Oracle America. V. Google Inc. Mayo 4 de 20014. p 18.

[8] Ibídem. p 23 – 25.

[9] Ibídem. p 31.

[10] “Because copyrightability is focused on the choices available to the plaintiff at the time the computer program was created, the relevant compatibility inquiry asks whether the plaintiffs choices were dictated by a need to ensure that its program worked with existing third-party programs. Whether a defendant later seeks to make its program interoperable with the plaintiff`s programs has no bearing on whether the software the plaintiff created had any design limitations dictated by external factors.” Ibídem. p 49.

[11] “No matter how much creativity might have gone into the design of the existing program’s interfaces and no matter how many choices the first programmer had when creating this design, once that the API exists, it becomes a constraint on the design of follow-on programs developed to interoperate with it.” SAMUELSON. Pamela. Guest Post: Are APIs Patent or Copyright Subject Matter? May 12, 2014.

[12] Ibídem.

[13] U.S. Supreme Court. ALICE CORPORATION PTY. LTD, PETITIONER v. CLS BANK INTERNATIONAL ET AL. junio 19 de 2014.

[14] Las patentes cedidas a Alice Corp. reivindican “(1) un método para el intercambio de obligaciones financieras, (2) un sistema de ordenador configurado para llevar a cabo el método para el intercambio de obligaciones, y (3) un código de programa de medio que contiene legible por ordenador para realizar el método de intercambio de obligaciones.” Ibídem.