CAPITULO V VEREDICTO DEL JURADO Y SENTENCIA DE LA CORTE DE DISTRITO [69] NORTE DE CALIFORNIA [70]
Con fecha 7 de mayo de 2012, el Jurado emitió un veredicto por el cual encontró que Google había infringido los derechos de autor de Oracle en relación a los 37 paquetes de Java [71]. A su vez, el mismo Jurado con fecha 23 de mayo de 2012 entendió que Google no infringía los derechos de patentes de Oracle [72] en relación a las reivindicaciones 11, 27, 29, 39, 40 y 41 de la patente RE 38104, y de las reivindicaciones 1 y 20 de la patente 6.061.520. Por otra parte, el 31 de mayo y 20 de junio de 2012, el Juez de la Corte del Distrito Norte de California, Willian Alsup [73] dicto sentencia, reversando el veredicto del Jurado en cuanto expresó que los paquetes de las API de Java y su estructura, secuencia y organización no eran protegibles bajo el sistema de derechos de autor de EE.UU. William Alsup recalcó que el presente caso se encuentra regido por los siguientes principios aplicables:
(i) Bajo la doctrina de fusión (en inglés “merge doctrine”) cuando hay una sola manera (o muy pocas) de expresar algo, entonces nadie puede reclamar titularidad sobre esa expresión bajo la ley de derechos de autor de EE.UU.; (ii) Bajo la doctrina de nombres, los nombres y las frases cortas no son protegibles bajo la ley de derechos de autor de EE.UU.; (iii) Bajo la sección 102, inciso b) la protección otorgada por los derechos de autor de EE.UU. no se extiende a las ideas, procedimientos, procesos, sistemas, métodos de operación o conceptos sin importar su forma. Los elementos funcionales esenciales para la interoperabilidad no son protegibles bajo la ley de derechos de autor de EE.UU., y, por último, (iv) Bajo la teoría del caso Feist, indicándose que no se debería reconocer protección por el sistema de derechos de autor de EE.UU. simplemente para recompensar una inversión realizada.
FUNDAMENTOS DE LA SENTENCIA DE LA CORTE DE DISTRITO DEL NORTE DE CALIFORNIA, JUEZ WILLIAM ALSUP [74].
Menciona el Juez de la Corte de Distrito que, en el mes de agosto del año 2010, Oracle demandó a Google por infracción a sus derechos de autor y a sus derechos de patentes de invención. Para ello, Oracle argumentó que la plataforma Android infringía los derechos de autor y de patentes de invención que Oracle poseía sobre la tecnología Java. Específicamente, en relación a los derechos de autor, Oracle argumentó que Google infringía sus derechos en relación a 37 paquetes de la librería estándar de Java o Java API. Los argumentos brindados por el Juez de la Corte del Distrito para rechazar la demanda de Oracle fueron los siguientes.
IMPLEMENTACIÓN INDEPENDIENTE POR PARTE DE GOOGLE Un punto central que remarca la sentencia de primera instancia es que ambas partes estuvieron de acuerdo en que Google no había copiado en forma “literal” el software bajo disputa, sino que, por el contrario, que Google había realizado su propia implementación de los 37 paquetes de la librería estándar de Java (“Sun Java Standard Library” o “Class Library”).
ESTRUCTURA, SECUENCIA Y ORGANIZACIÓN El Juez de la Corte de Distrito menciona que el reclamo neurálgico de Oracle “debería ser” que Google copió la estructura, secuencia y organización del total de los 37 paquetes de la librería estándar de Java. Ello por cuanto se entendió que mientras los nombres no están protegidos por el sistema de derechos de autor de EE.UU., el sistema de nombres organizados de Java -que abarca a los 37 paquetes con sus 600 clases y sus más de 6000 métodos- conforma una estructura organizacional o taxonomía, protegible bajo la ley de derechos de autor de EE.UU. Ahora bien, por otro lado, el hecho de que un método de operación posea miles de comandos seleccionados en una taxonomía creativa no le cambia el carácter de método de operación. El Juez de Distrito expresó: “Si es creativo. Si es original. Sí se asemeja a una taxonomía. Pero constituye una estructura de comandos, un sistema o método de operación. Por esta razón no puede ser protegido por el derecho de autor -tal vez por el sistema de patentes”. Es decir, la Corte de Distrito reconoció que la estructura, secuencia y organización de las API de Java era original y creativa, pero menciona que “la estructura, secuencia y organización de comandos” no es más que un método para operar, un método de operación, que se encuentra excluido del sistema de protección de derechos de autor de EE.UU. (US Copyright Law, Titulo17, sección 102, inciso b). También al respecto de la estructura de las API se expresa que la misma funcionalidad podría haber sido ofrecida en Android sin haberse tenido que copiar la misma estructura de comandos usados en Java. Es más, podría haber sido hecho mediante una suerte de reorganización de los métodos bajo diferentes grupos entre las distintas clases y paquetes de Java -aún, usando los mismos nombres que en Java-. También en el momento de la creación de Java por parte de Sun Microsystems había muchas maneras de agrupar a los métodos, y, así y todo, se podría haber duplicado el mismo rango de funcionalidad. De todas formas, teniendo en cuenta que la estructura de comandos es un sistema o un método para operar conforme a lo establecido en la sección 102 b) de la ley de derechos de autor de EE.UU. no puede ser protegida. La sección 102, inciso b) menciona lo siguiente: “...en ningún caso la protección del derecho de autor para las obras originales se extiende a las ideas, procedimientos, procesos, sistemas, métodos de operación...sin importar la forma...” Y por último al respecto de su exclusión de protección, se dijo que no es menos cierto que los nombres serían más que nombres, así serían una suerte de símbolos en una estructura de comandos en donde los comandos toman la forma de expresión de java.package.Class.method(). Entonces cada comando posee una función pre-asignada. En definitiva, el “árbol de nombres”, posee un elemento creativo, pero es también una estructura de comandos, una suerte de conjunto utilitario y funcional de símbolos, cada uno de ellos con una función pre-asignada. Y por ello su exclusión de la protección de la ley de derechos de autor.
NO IMPORTA QUE TAN CREATIVO O IMAGINATIVO PUEDA SER UN MÉTODO DE JAVA, CUALQUIERA TIENE DERECHO A UTILIZAR LA MISMA ESPECIFICACIÓN DEL MÉTODO (INPUTS, OUTPUTS, PARÁMETROS) SIEMPRE Y CUANDO Y LÍNEA POR LÍNEA, EL CÓDIGO FUENTE IMPLEMENTADO SEA DIFERENTE Siempre que el código que se utilice para implementar un método de Java sea diferente, cualquier persona puede conforme al derecho de autor de EE.UU. escribir su propio código fuente para llevar a cabo exactamente la misma función o especificación de cualquier método de Java utilizado en la librería estándar de Java. Expresa la Corte del Distrito que contrariamente a lo que sostiene Oracle, el sistema de derechos de autor EE.UU. no confiere derechos sobre todas y cada una de las formas de llevar a cabo la implementación de una función o especificación, ello es así, sin importar que tan creativo pueda ser la implementación o especificación. Agrega que la ley sólo confiere derechos sobre la manera específica en que un autor ha creado su propia versión. Por ende, cualquier otro individuo puede desarrollar o escribir su propia implementación para llevar a cabo o cumplir con idéntica funcionalidad, por lo tanto, las ideas, conceptos y funciones no pueden ser monopolizadas por el sistema de derechos de autor de los EE.UU. Al respecto del ejemplo del método de Java que se ha mencionado anteriormente, en donde una función de comparar dos números y devolver como resultado el mayor de ellos, el Juez menciona que Google, -y cualquier otro- tiene derecho a escribir su propio código para llevar a cabo la misma función siempre que el código implementado en el cuerpo del método sea diferente de la implementación protegida (la implementación protegida a la que se refiere es a la realizada por Sun Microsystems, Inc., es decir la Java Class).
IMPOSICIÓN DE LOS “HEADERS” POR REGLAS DEL LENGUAJE DE PROGRAMACIÓN JAVA No importa que las declaraciones (en inglés “declarations” [75]) o las líneas de encabezados (en inglés “headers”) de un método sean idénticas, ya que, conforme a las reglas del lenguaje de programación Java deben ser idénticas para declarar el mismo método especificando la misma funcionalidad, aún, cuando su implementación sea diferente.
LOS MÉTODOS DE JAVA COMO “MÉTODOS DE OPERACIÓN” PODRÍAN SER PROTEGIDOS BAJO EL SISTEMA DE PATENTES DE INVENCIÓN Agrega la Corte de Distrito que gran parte de la prueba rendida en el juicio por Oracle se enfocó en mostrar que los métodos en la Java Class tenían un esfuerzo creativo: Alsup, menciona que es cierto, que es así, y agrega que inventar un nuevo método de Java (en inglés “Java method”) para entregar un nuevo resultado (en inglés “output”) puede ser creativo, incluso puede tener altura inventiva, incluyendo las opciones del input necesario y sus outputs. Lo mismo aplica para las clases de Java (“Java Classes”). Ahora, tales invenciones -en cuanto al concepto y al nivel funcional- son protegidas únicamente por el derecho de patentes de invención.
DOCTRINA DE LA FUSIÓN (“MERGE DOCTRINE”) Se menciona que cuando existe una sola forma de expresar una idea o una función, cualquier persona es libre para expresar esa idea, y nadie puede monopolizarla, justamente porque existe una sola forma de expresarla. Y si bien los métodos de Android y los nombres de clases (en inglés “class name”) podrían haber sido diferentes de aquellos nombres utilizados por Oracle en Java -y aún, así habrían funcionado de igual forma- el derecho de autor de EE.UU. no se extiende, y por ende no protege, a los nombres o las frases cortas.
INTEROPERABILIDAD Al respecto de este punto, opina el Juez de grado que la duplicación de la estructura de comandos es necesario para la “interoperabilidad” diciendo que seguramente millones de líneas de código han sido escritas en lenguaje Java antes que Android existiera. Estos programas necesariamente utilizaron el formato de comando java.package.Class.method(). Así estos programas llamados o invocados en todos o algunos de los 37 paquetes en cuestión, necesariamente usaron los comandos y su estructura de nombres. Ese código era de propiedad de los propios programadores (terceros), y no de Oracle. En el caso en cuestión, para que al menos parte de este código corriera en Android, Google era requerido de proveer el mismo idéntico sistema de comando java.package.Class.method() utilizando los mismos nombres asignados con la misma taxonomía y con la misma funcionalidad. Por lo tanto, concluye el Juez de la Corte del Distrito que Google replicó aquello que era necesario para tener un grado de interoperabilidad -pero no más allá de ello, creando y desarrollando así su propia implementación independiente.
FRAGMENTACIÓN (O “BALKANIZATION”). LOS CASOS SONY Y SEGA
En relación a la denominada “fragmentación” o “balkanization”, y de porque los casos judiciales de SONY y SEGA son similares a este caso, se expresa que la interoperabilidad se encuentra en el corazón de la estructura de comandos, ilustrada por la misma preocupación de Oracle en lo que denomina “fragmentación”, queriendo referirse al problema de tener una “interoperabilidad imperfecta” entre plataformas.
Cuando esto ocurre, las aplicaciones basadas en Java no pueden correr o ejecutarse en plataformas que no son compatibles.
Sun Microsystems y Oracle han tratado de evitar esta balkanization a través de sus programas de licenciamiento (recuérdese que existían tres (3) modelos: a) licencia GPL v2 más ClassPath Exception (“open source”), b) licencia de especificación, y c) licencia comercial.
Expresa el Juez de Distrito, que Oracle ha dejado la impresión que sí Google hubiese copiado “todos” los 166 paquetes de la librería estándar de Java, Oracle no habría demandado a Google.
Recordemos que Oracle demandó a Google soló por la infracción de 37 paquetes, por lo tanto, no hay reclamo de infracción de derechos de autor por los restantes 129 paquetes que conformaban la librería estándar de Java en la edición 2 de la plataforma Java al momento de la demanda.
Mientras la “fragmentación” es una consideración de negocio legítima de ser considerada hace nacer la pregunta de si una licencia era o no requerida para replicar “parcial o totalmente” la estructura de comando (claro y sólo si y en la medida de que Android no llevara la marca registrada Java, y que Google no sostuviera que Android es totalmente compatible con Java).
Por otro lado, las decisiones judiciales del Circuito Noveno de SEGA y SONY, tienen cierta similitud con el caso en cuestión, ya que en estas dos decisiones judiciales se dijo que los “procesos de interfaces requeridos o necesarios” para la interoperabilidad fueron considerados como “requerimientos funcionales para la compatibilidad” y se los consideró como no protegibles por el derecho de autor de EE.UU. conforme lo establecido en la Sección 102, inciso b).
Agrega el Juez que en ambas decisiones judiciales se sostuvo que los procesos de interface que eran necesarios de ser duplicados con el objetivo de garantizar la compatibilidad fueron considerados “aspectos funcionales” y, por lo tanto, no protegibles a la luz de la sección 102, inciso b) de la ley de derechos de autor de los EE.UU.
Por tanto, sostiene la Corte de Distrito que en el caso en cuestión, y en el mismo sentido reflejado anteriormente, la estructura de comandos para los 37 paquetes de Java es análoga a los casos de SEGA y SONY diciéndose que si alguien pudo replicar las interfaces de la BIOS de SONY con el objetivo de hacer correr los juegos de la Playstation en computadoras de escritorios (escribiendo su propia implementación), entonces Google podía duplicar la estructura de comandos de los 37 paquetes en Android con el objeto de acomodar el código fuente de terceros confiando en los 37 paquetes (de nuevo con su propia implementación).
Por ello dice la Corte de Distrito, que “la compatibilidad total” no es relevante a los efectos del análisis de la Sección 102, inciso b), y agrega que en el caso SONY, el producto acusado de infracción únicamente implementó 137 funciones de las 242 funciones de la BIOS de la PlayStation porque eran las únicas funciones invocadas por los juegos.
Por ello la Corte de Apelaciones en ese caso sostuvo que el producto acusado de infracción no infringía o violaba la ley de derechos de autor de EE.UU.
Al respecto la Corte de Distrito expresa que ello traza un paralelo con la decisión que tomó Google de implementar “sólo algunos, pero no todos” de los paquetes de la librería estándar de Java en Android.
RAZONES POR LAS CUALES EL CASO AMERICAN DENTAL ASSOCIATION (ADA) V. DELTA DENTAL PLANS ASSOCIATION (DECISIÓN JUDICIAL DEL CIRCUITO SÉPTIMO) NO CONTROLA EL PRESENTE CASO JUDICIAL Asumiéndose que en el Circuito Noveno la taxonomía es materia protegible del derecho de autor (y cita como referencia el caso Practice Mgmt. Info v. Am. Med. Ass´n, del Circuito Noveno del año 1997), se expresa que la taxonomía en ADA no tenía nada que ver con programas de computación, y que no se trataba de un sistema de comandos, y mucho menos de un sistema de comandos para un lenguaje de computación. Así, la taxonomía en ADA subdividía todos los procesos dentales dentro de un esquema de categorías numeradas con una descripción en idioma inglés creada por ADA. Esto era usado posteriormente por las compañías de seguro y dentistas para facilitar la facturación. Por el contrario, la taxonomía en el caso Oracle v. Google, se compone en su totalidad por un sistema de comandos para llevar a cabo funciones de computadoras. Agrega que, en el caso ADA, se sugirió que un “sistema”, bajo la Sección 102 inciso b), debía venir con “instrucciones para uso”. Ahora bien, como la taxonomía en ADA no tenía instrucciones para ser usada, se consideró que no era un sistema -además y entre otras razones-. Por el contrario, los paquetes de Java en cuestión vienen con instrucciones de uso, como ser la documentación y los comentarios embebidos. Estos describen cada uno de los paquetes, clases y métodos, que inputs se necesitan, y que outputs se devolverá-la clásica forma de instrucciones de uso-.
PORQUE NO ES CORRECTA LA VISIÓN DE ORACLE RESPECTO DEL CASO JOHNSON CONTROLS V. PHOENIX CONTROL SYS [76] (CIRCUITO NOVENO, DEL AÑO 1989) Se sostiene que no es correcta la visión de Oracle de lo resuelto en el caso Johnson Controls V. Phoenix Control Sys. Así se dice que en el Circuito Noveno (que es el Circuito al cual pertenece la Corte del Distrito de California a cargo de William Alsup) la estructura, secuencia y organización de un programa de computación puede o no calificarse como un elemento protegible dependiendo “de los hechos particulares de cada caso” y siempre sujeto a la exclusión de elementos no protegibles. Explica que contrariamente a lo que sostiene Oracle, el caso Johnson Controls no sostuvo que toda estructura, secuencia y organización en un programa de computación estaba dentro del ámbito de protección del derecho de autor de EE.UU. Por el contrario, en ese caso se encontró que la estructura, secuencia y organización -del programa que en sí mismo se entendía protegido- teniendo en cuenta los hechos particulares del caso, merecía protección bajo la ley de derechos de autor de EE.UU. El Juez Alsup expresa que las circunstancias del caso Johnson Controls v. Phoenix Control no son las mismas circunstancias del caso Oracle v. Google.
PORCENTAJES Del total de los 166 paquetes en Android, existen 129 paquetes por los cuales no se ha demandado por infracción derechos. De los 37 paquetes demandados, el 97% de las líneas de código de Android fueron escritas por Google, y respecto del 3 % restante expresa la Corte del Distrito que eran replicables bajo la teoría de la fusión y la teoría de nombres.
ELEMENTOS PARTICULARES DEL CASO La sentencia no expresa que los paquetes de la librería estándar de Java pueden ser usados sin licencia alguna, como tampoco sostiene que la estructura, secuencia y organización de todos los programas de computación pueden ser “robados”. Muy por el contrario, sostiene que “ante los hechos específicos del caso, los elementos particulares copiados por Google podían ser utilizados bajo la ley de derechos de autor de EE.UU.”. Durante el mes de febrero del año 2013 se presentaron diferentes opiniones de los Amicus Curiae (amigos del tribunal) soportando o apoyando la posición de cada una de las partes litigantes. Asimismo, fueron presentadas las apelaciones correspondientes.