Backlab06
commented
2 years ago Tengo un problema ya que mi celular tiene Google pero al parecer esta compilado de tal manera que es un que el sistema operativo no es el original, que puedo hacer en estos casos, ya he buscado pero no encuentro nada
CAPITULO VII
SENTENCIA I DEL TRIBUNAL DE APELACIONES DEL CIRCUITO FEDERAL DE EE.UU [77]
PROTECCIÓN DE LAS API DE JAVA Y DE SU ESTRUCTURA, SECUENCIA Y ORGANIZACIÓN
Con fecha 9 de mayo de 2014 la Corte Federal de Apelaciones [78] integrada por los jueces O´Malley, Plager y Taranto determinaron que el código fuente declarado y la estructura, secuencia y organización de los 37 paquetes de las API de Java estaban sujetas a protección bajo las leyes del derecho de autor de EE.UU.
Es decir, la sentencia del Tribunal de Apelaciones del Circuito Federal reversó la sentencia dictada en la primera instancia por la Corte de Distrito del Norte de California en materia de protección bajo el derecho de autor del código fuente declarativo de los 37 paquetes de las API de Java y de su estructura, secuencia y organización, ordenándose reestablecer la decisión del Jurado que había determinado oportunamente la protección de la estructura, secuencia y organización de las API de Java bajo el sistema de derecho de autor de EE.UU.
Por otra parte, el Tribunal de Apelaciones del Circuito Federal mandó a que el Jurado tratara el asunto de “fair use”.
Tal como se había mencionado durante el trámite del pleito, el Tribunal de Apelaciones del Circuito Federal mencionó que cada paquete de Java posee dos tipos de código fuente, y que las partes lo han llamado código declarado (en inglés “declaring code”) y código implementado (en inglés “implementing code”).
Código declarado es la expresión que identifica a las funciones pre-escritas y que se lo ha denominado como “declaración” o header (lo que es lo mismo que “encabezado”).
El header introduce el cuerpo del método (“method body”) y especifica con precisión el input, el nombre y otras funcionalidades.
A su vez, las expresiones utilizadas por un programador desde el código declarado instruyen a la computadora para ejecutar el código implementado asociado, el que le da a la computadora las instrucciones del paso a paso para llevar adelante la función declarada.
El Tribunal de Apelaciones del Circuito Federal menciona que Google adquirió la empresa Android, Inc. en el año 2005 con la idea de desarrollar una plataforma para teléfonos móviles inteligentes.
En el mismo año, Google y Sun Microsystems comenzaron a discutir la posibilidad de que Google tomara una licencia para usar y adaptar la plataforma Java para dispositivos móviles.
De hecho, las partes trataron la posibilidad de tener un acuerdo de colaboración bajo el cual la tecnología Java sería “una parte del código abierto” de la plataforma Android.
El punto de desencuentro entre las partes era la negativa de Google de hacer la implementación de sus programas compatibles con la máquina virtual de Java (JVM) o hacerlos interoperables con otros programas de Java.
Oracle sostuvo que la posición de Google era contraria al principio de “write once, run anywhere”, y, por ende, decidió no otorgar una licencia sobre los paquetes de las API de Java a Google.
Posteriormente a ello, ya suspendidas las negociaciones entre las partes, Google decidió utilizar el lenguaje de programación Java para construir su propia máquina virtual llamada Dalvik (“Dalvik Virtual Machine o DVM”).
También, Google desarrolló su propia implementación para las funciones de los paquetes de la API de Java que eran claves o necesarias para los dispositivos móviles.
Así Google desarrolló su plataforma Android que incluyen 168 paquetes de API, 37 de los cuales corresponden a los paquetes de las API de Java en debate en el pleito.
En relación a los 37 paquetes de las API de Java en cuestión, dice el Tribunal de Apelaciones del Circuito Federal que Google creía que los desarrolladores esperarían encontrar el mismo set de las 37 funcionalidades en el mismo sistema de llamadas de Android bajo los mismos nombres utilizados por Java.
Por lo que, para obtener dicho resultado, Google copió en forma idéntica el código fuente declarado (en inglés “declaring source code”) de las API de los 37 paquetes de Java, insertando el código declarado en Android.
Al efectuarse ello, Google copió la estructura organizacional de todos los nombres de los métodos, clases, interfaces, y paquetes, cubriendo los 37 paquetes con sus 600 clases y con más de sus 6000 métodos de Java.
Por otra parte, se agrega que no hay dudas de que Google escribió su propia implementación [79] y, por otro lado, a pesar de que Android fue escrita en lenguaje Java, Google diseño Android para que no fuera compatible con la plataforma Java, es decir que una aplicación escrita para la plataforma Android no funcionara en la plataforma Java.
Menciona el Tribunal de Apelaciones del Circuito Federal que está claro que Google podía haber escrito o desarrollado sus propios paquetes de las API de Java usando el lenguaje Java, pero Google escogió no hacerlo.
En su lugar, Google copió 7000 líneas de código fuente declarado replicando el total de la estructura, secuencia y organización de los 37 paquetes de las API de Java.
Conforme Google:
(i) había una sola manera de escribir las declaraciones de los métodos de Java, y
(ii) la organización y la estructura de los 37 paquetes de las API de Java conforma una “estructura de comandos” que se encuentra excluida de protección conforme al artículo 102 inciso (b) de la ley de derechos de autor de EE.UU.
El tribunal de Apelaciones del Circuito Federal afirma que ello no es correcto.
Por su parte el Tribunal de Apelaciones del Circuito Federal expresa que el Juez del Distrito se ha equivocado y no ha distinguido correctamente la cuestión principal acerca de cuál es la diferencia entre:
(i) aquello que es susceptible de ser protegido bajo la ley de derecho de autor bajo el sistema de EE.UU. (en inglés “copyrightable”), y
(ii) la conducta que constituye infracción de derechos de autor (en inglés “infringing activity”)
PROTECCIÓN BAJO EL SISTEMA DE DERECHOS DE AUTOR DE EE.UU.
La ley de derechos de autor de EE.UU. proporciona protección “a las obras originales de autores que hayan sido fijadas en un medio tangible de expresión”, lo cual incluye a las obras literarias (USC por “United States Code” o Código de los Estados Unidos de América, Titulo 17, Capitulo 1, sección 102, inciso a [80]).
Por otra parte, los programas de computación se encuentran definidos como “el set de declaraciones o instrucciones para ser usados directa o indirectamente por una computadora con el objeto de producir un resultado cierto” [81].
Así, los programas de computación pueden estar sujetos a la protección bajo las leyes de derechos de autor de EE.UU. como “obras literarias” (Atari Games Corp v. Nintendo of Am., Inc. 975 F.2d 832, 838 (Fed. Cir. 1992) (“como obras literarias, la protección bajo las leyes de derechos de autor de EE.UU. se extiende a los programas de computación).
Por su parte, para que una obra pueda ser protegida bajo el sistema de derechos de autor debe ser o estar calificada como “original” (USC Titulo 17, sección 102, inciso a).
El requisito de la originalidad no es particularmente exigente.
El vocablo o término “originalidad” tiene un significado propio para la ley de derechos de autor que implica que la obra en cuestión haya sido creada en forma independiente, en el sentido que no sea copia de otra, y claro que esa originalidad posea un cierto grado mínimo de creatividad.
Por otro lado, la protección brindada por el derecho de autor de EE.UU. sólo se extiende a la “expresión de las ideas” y no a las ideas en sí mismas (Mazer v. Stein, 347 U.S. 201 217 (194).
Esta distinción se la conoce como la dicotomía o división de la idea y su expresión que se codifica en el artículo 102 inciso (b), que dice textualmente:
También, la protección de derechos de autor se extiende a los elementos literales y a los no-literales de un programa de computación.
Los elementos literales de un programa de computación son el código fuente y el código objeto [82].
Los elementos no-literales de un programa de computación, entre otros, es la estructura, secuencia y organización del programa.
Si los elementos no-literales de un programa de computación están o no protegidos depende de las circunstancias particulares de cada caso.
El reclamo de Oracle en materia de derechos de autor bajo la ley de EE.UU. se refiere a dos aspectos sobre los que entiende que debe existir protección:
(i) los elementos literales de los paquetes de las API de Java (las 7000 líneas de “código fuente declarado”) y,
(ii) los elementos no literales de cada uno de los 37 paquetes de las API de Java, es decir su estructura, secuencia y organización (su sigla en inglés “SSO”)
El Tribunal de Apelaciones del Circuito Federal marca un importante asunto que es la diferencia entre:
(i)aspectos literales y no-literales de un programa de computación, y la
(ii) copia literal y no-literal (Altai, 982 f.2d en 701-02). La copia literal es la “copia exacta” de la expresión original. La copia no-literal es una suerte de “parafraseo” en lugar de copiar palabra por palabra. En el caso de autos, Google aceptó que había copiado el código fuente declarado “verbatim” en forma exacta, textual, literal, palabra por palabra.
Oracle ha mencionado que el código fuente declarado se incorpora a la estructura de cada paquete de las API de Java.
Por ello cuando Google copió el código declarado en esos paquetes de Java también copio la secuencia y organización de cada uno de los paquetes utilizada por Oracle.
También Oracle menciona que los elementos no-literales de los paquetes de las API de Java, es decir su estructura secuencia y organización que llevaron al código implementado por Google, está sujeta a la protección otorgada por la ley de los derechos de autor de EE.UU.
Por ello, Oracle no argumenta que exista copia literal de la totalidad de la estructura, secuencia y organización, sino que afirma que Google copio literalmente el código declarado y luego parafraseó el resto de la estructura secuencia y organización cuando escribió su propio código fuente implementado.
Por ello, Oracle afirma que existe copia no literal de parte de Google respecto de la totalidad de la estructura, secuencia y organización.
Por otra parte, teniendo en cuenta las declaraciones testimoniales en el juicio quedo probado que el código fuente declarado y su estructura, secuencia y organización de los paquetes de las API de Java eran originales.
Así, surge de estas constancias que el diseño de los paquetes de las API de Java era un proceso creativo [83], y que los desarrolladores de Sun Microsystems /Oracle tuvieron varias opciones para estructurar y organizar las API.
También, esto fue reconocido por el propio Juez de Distrito, y por Google, que no disputó lo dicho por el Juez de Distrito en cuanto a que las API de Java cumplían con el requisito de originalidad.
Dicho lo anterior, puede verse entonces que las partes estuvieron de acuerdo en que los paquetes de las API de Java cumplían con el requisito de originalidad requerida de acuerdo con el artículo 102, inciso (a), pero no estaban de acuerdo en la interpretación y aplicación del artículo 102, inciso (b).
Así, Google sostuvo al respecto que hay dos pasos en el análisis de la protección bajo derechos de autor, en donde el artículo 102, inciso (a) concede protección a las obras originales, mientras que el inciso (b) del mismo artículo 102, quita la protección a la obra en cuestión si ésta posee elementos funcionales.
A los ojos del Tribunal de Apelaciones del Circuito Federal esta interpretación de Google es incorrecta, ya que el Congreso de los EE.UU. ha enfatizado que el artículo 102 inciso (b) “...de ninguna manera extiende o contrae el ámbito de protección conferido por el derecho de autor...” “...y que su propósito es reafirmar...” y que “el principio básico entre la división de idea y expresión se mantiene inalterado...”.
Por lo tanto, el artículo 102, inciso (b) no extingue la protección acordada a la expresión de una idea por la sola circunstancia que dicha expresión se haya incorporado en un método de operación.
Menciona el Tribunal de Apelaciones del Circuito Federal que las Cortes de Distritos no están en un todo de acuerdo en relación a que “examen o test” se debería utilizar para marcar una línea entre lo que constituye una expresión protegible por el derecho de autor de EE.UU. y lo que no.
Por ejemplo, en el caso Whelan Assocs. Inc v. Jaslow Deantal Lab se dijo que todo aquello que no fuera necesario para el propósito o funcionamiento de una obra constituye expresión protegible, y en el caso Lotus se sostuvo que un método para operar es el medio mediante el cual un usuario puede operar algo.
Por el contrario, conforme el Circuito Noveno (que como se mencionó anteriormente por parte del Juez de la Corte de Distrito constituye ley aplicable al caso en cuestión) a los fines de determinarse si los elementos no-literales de un programa de computación constituyen una expresión protegible bajo la ley de derechos de autor se utiliza el examen o test desarrollado por el Tribunal de Apelaciones del Circuito Federal del Circuito Segundo, conocido como test de “abstracción, filtración y comparación”.
Este examen descarta la idea de que por “el sólo hecho de que cualquier cosa ejecute una función no pueda ser protegido”, es decir, aunque un elemento de una obra pueda ser caracterizado como un “método de operación”, ese elemento, puede, sin embargo, contener un grado de expresión que lo haga elegible para ser protegido por el derecho de autor.
De alguna forma este examen descarta la posición de los casos Lotus (todo aquello que ejecuta una función ya no es protegible) y Whelan (una vez identificadas las ideas de un programa de computación, todo el resto es expresión protegible, en este caso sobre la base que más de una idea pueda estar incorporado en un programa de computación)
Ahora bien, este examen en su totalidad, es decir en sus tres etapas (abstracción, filtración y comparación), sólo aplicaría ante los casos donde el titular de derechos alega infracción de elementos no-literales.
En el caso en cuestión, donde se ha admitido por parte de Google la copia literal del código fuente declarado no es requerido, ya que no hace falta realizar un examen completo (de las tres etapas abstracción, filtración y comparación), sino que alcanza con realizar la etapa de “filtración”, que es la etapa en donde se focaliza en la protección de la obra conforme a los principios del derecho de autor (en inglés “copyrightability”). Es decir, si es protegible o no.
De las constancias de autos, si bien es cierto que se mencionó por el Juez de la Corte de Distrito el examen o test en cuestión, pareciera según se afirma que no se lo aplicó.
En efecto, en su lugar cuando se analizó el código fuente declarado, el Juez de Distrito concluyó e interpretó directamente el artículo 102 inciso (b) como “una prohibición de protección de cualquier elemento funcional que “sea esencial para la interoperabilidad” sin importar su forma.
El Tribunal de Apelaciones del Circuito Federal sostiene que invocar la “interoperabilidad” en el análisis de protección por derechos de autor es incorrecto, y que el Juez del Distrito yerra en este aspecto.
Sostiene que la interoperabilidad es un elemento que debe tenerse presente en el análisis de uso justo, pero no en el análisis de si una obra merece o no protección conforme a la ley de derechos de autor de EE.UU. (en inglés “copyrightability”).
DOCTRINA DE LA FUSIÓN (“MERGE DOCTRINE”) [84]
La doctrina de la fusión funciona como una excepción a la dicotomía o división entre la idea y su expresión.
Esta doctrina reza que cuando existe un número limitado de maneras de expresar una idea, se dice que la idea “se ha fusionado” con su expresión, y entonces la expresión se torna no protegible por el derecho de autor del sistema de EE.UU. (en inglés “Copyright Law”).
En definitiva, una supuesta obra protegida bajo derechos de autor no podría tener protección judicial por infracción de derechos, si la idea contenida en dicha obra sólo podría expresarse de una sola manera.
Menciona el Tribunal de Apelaciones del Circuito Federal que el Circuito Noveno trata este concepto de la fusión de “idea/expresión” como una “defensa afirmativa cuando se alega una infracción”, entonces el análisis no es relevante a la hora de analizar “la protección bajo la ley de derechos de autor de los paquetes de Java” (en inglés “copyrightability”).
Recuérdese que según la Corte de Distrito bajo las reglas de Java un programador debe usar idénticas declaraciones o líneas de encabezados (en inglés “headers”) para declarar un método especificando la misma función.
Por lo tanto, expresaba el Juez de Distrito que como hay una sola manera de escribir el código declarado para cada uno de los paquetes de Java, la idea (método declarado) se fusiona con la expresión (código implementado), y concluye que nadie podría reclamar derechos sobre ello, ya que no es protegible bajo el sistema de derechos de autor.
A este respecto dice el Tribunal de Apelaciones del Circuito Federal que nuevamente la Corte de Distrito se equivoca, ya que aplica erróneamente la doctrina de la fusión.
En efecto dicha teoría aplicaría sólo sí al momento, o en el tiempo, en que hubiese sido creado por Oracle el código declarado hubiese podido haberse hecho de una sola manera.
Es decir, que en aquel tiempo “Oracle sólo hubiese tenido una sola opción” (porque sólo existe una sola opción).
Ahora, está probado en el juicio que Oracle tuvo infinidad de opciones para organizar y seleccionar las 7000 líneas de código que Google copió.
Así el método de Java utilizado como ejemplo (java.lang.Math.max) podría haber sido llamado y organizado como “Math.maximun” o “Arith.larger”.
En definitiva, la doctrina de la fusión (acerca de las opciones de como expresar una idea) se tiene en cuenta al momento de la creación de la obra, y no al momento de la infracción.
Vale decir, no interesa que opciones de expresar esa idea tenía el copista (al momento de copiar), sino su creador (al momento de crear).
Por lo tanto, como existieron múltiples alternativas de expresión al momento de creación del código declarado para Oracle, el Tribunal de Apelaciones del Circuito Federal rechazó la aplicación de la doctrina de la fusión.
FRASES CORTAS Y NOMBRES
Se sostuvo que es cierto que las palabras, las frases cortas como nombres, títulos y eslogan no están sujetos a derechos de autor bajo el sistema de EE.UU. -si bien como obras literarias usualmente lo son-.
Ahora bien, a los efectos de responder la pregunta sobre si existe protección bajo derechos de autor, la cuestión no era analizar si la obra en cuestión que contenían frases, eran cortas o no, sino más bien analizar si ellas “eran creativas” o no.
Al diseccionarse en forma individual las líneas de código declarado en frases cortas, la Corte de Distrito erró en reconocer una combinación original de elementos que puede ser protegido.
Oracle ejerció creatividad en la selección y disposición de sus métodos declarados cuando creó los paquetes de la API de Java, escribiendo su propio código declarado, lo cual posee expresiones protegibles que son susceptibles de ser protegidas por el derecho de autor.
Por estas razones se concluye que no es correcta la visión de la Corte de Distrito y se rechaza sus argumentos.
DOCTRINA DE “SCENES A FAIRE”
La doctrina de la “scenes a faire” limita a ciertas obras creativas de protección bajo la ley de derechos de autor.
Bajo esta doctrina se establece que las obras no pueden ser protegidas en contra de infracciones si son estándares o comunes dentro de un género o tópico, o si son necesarias de ser seguidas conforme a determinado tema.
En el juicio se rechazó la postura de Google en relación a la doctrina del scenes a faire.
En primer lugar, se encontró que Google no había presentado suficiente evidencia que mostrase que agrupar a los métodos dentro de las clases, o las clases dentro de los paquetes constituyera una práctica común y esperada.
En la instancia anterior se sostuvo que es imposible decir “que todas las clases y sus contenidos es típico de esas clases”.
A su vez, al igual que la doctrina de la fusión, en la doctrina del scenes a faire el foco de las circunstancias debe ser evaluada al momento de la creación, y no de la copia o infracción.
Es decir que las circunstancias de si agrupar clases y todos sus contenidos dentro de una clase es o no típico o esperado, se debe evaluar al momento en que Oracle creó y dispuso esa agrupación, y no al momento en que Google lo copió.
Por estas razones el Tribunal de Apelaciones del Circuito Federal rechazó la apelación de Google en relación a este punto, y sostuvo que la doctrina del “scenes a faire” no afecta la protección del código fuente declarado como tampoco de la estructura, secuencia y organización de los paquetes de las API de Java.
LA ESTRUCTURA, SECUENCIA Y ORGANIZACIÓN DE LOS PAQUETES DE LAS API DE JAVA
Para determinar que la estructura, secuencia y organización de las API de Java no eran protegibles bajo la ley de derechos de EE.UU., la Corte de Distrito sostuvo que más allá de reconocerle creatividad a la estructura, secuencia y organización de los 37 paquetes que forman parte de la librería de software estándar de Java, la misma constituye un método o sistema de operación, y por lo tanto no es protegible bajo el derecho de autor.
En arribar a esta conclusión, la Corte de Distrito basó su decisión en el caso Lotus Development Corp v. Borland International [85] resuelto por el Circuito Primero.
En el caso Lotus, el demandado había copiado la jerarquía de comandos del menú (print, quit, etc.) y sus interfaces del programa de computación Lotus 1-2-3, que era un programa de hojas de cálculo que permitía a los usuarios ejecutar funciones contables. Estos comandos estaban organizados en más de 50 menúes y sub-menúes.
Borland no copió código de Lotus, pero si copió la jerarquía de comandos del menú de Lotus para incluirlo en su programa.
La pregunta que se había generado en ese caso era si esa jerarquía de comandos del menú de un programa de computación era protegible bajo el sistema de derechos de autor.
A pesar de que la Corte de Distrito que llevo el caso había encontrado que en la disposición y selección de los comandos había cierta expresión creativa de parte de Lotus Development, el Tribunal de Apelaciones del Circuito Federal del Circuito Primero resolvió que la “jerarquía de comandos” no era protegible por el sistema de derechos de autor, ya que constituía un método para operar conforme a lo dispuesto en el artículo 102, inciso (b).
Así “método para operar” se lo definió como “los medios por los cuales una persona opera algo, lo cual podría ser un auto, un procesador de alimentos, o una computadora”
El Tribunal de Apelaciones del Circuito Federal expresa que la Corte de Distrito del Norte de California se equivoca al fundar su decisión en el caso Lotus, porque Lotus es distinto en cuanto a los hechos del caso en cuestión, y además es inconsistente con la ley aplicable para el Tribunal de Apelaciones del Circuito Federal del Circuito Noveno.
Para empezar, en el caso Lotus el demandado no copió código de Lotus, y en el caso en cuestión Google reconoció que había copiado el código fuente declarado de Oracle en forma idéntica.
En segundo lugar, en el caso Lotus los comandos (copy, print, etc.) que se discutieron no eran creativos, ahora no hay dudas de que el código fuente declarado y la estructura, secuencia y organización de las API de Java son creativas y originales.
Por último, mientras que en Lotus se estableció que los comandos eran “esenciales para operar” el sistema del programa Lotus 1-2-3, es indiscutible que Google no necesitaba copiar la estructura, secuencia y organización de los paquetes de las API de Java para escribir programas en lenguaje Java.
A su vez, el Circuito Noveno, no adoptó el razonamiento del caso Lotus en cuanto a “método de operación”, porque se afirma que es inconsistente con lo resuelto por el Tribunal de Apelaciones del Circuito Federal del Circuito Noveno donde se ha reconocido que la estructura, secuencia y organización de un programa de computación es elegible para la protección brindada por el derecho de autor en la medida que constituya la expresión de una idea, y no la idea en sí misma. (Johnson Controls, 886 F.2d en 1175-76).
Y se agrega, que mientras en el caso Lotus se sostuvo que “la expresión que es parte en un método de operación no es protegible por el derecho de autor”, el Tribunal de Apelaciones del Circuito Federal, tomando la doctrina aplicable del Circuito Noveno- concluye totalmente lo opuesto, ya que “el derecho de autor protege la expresión de un método de operación”.
Por lo tanto, se rechaza la teoría de Lotus dada por la Corte de Distrito del Norte de California, ya que no es aplicable, y además contradice el caso Johnson Controls que es el que rige para el Circuito Noveno.
Agrega el Tribunal de Apelaciones del Circuito Federal, que según la Corte de Distrito la estructura, secuencia y organización es creativa, pero sin importar ello constituye una estructura de comando para operar, es un “método de operación”, y por ende no es protegible bajo el sistema de derecho de autor.
Es decir, es creativa, expresa una idea, pero no es protegible porque es funcional.
El problema con esta visión, es que los programas de computación son por definición “funcionales”, es decir están designados para llevar a cabo una función.
Y esto es conforme a la “definición de programa” de computación, conforme artículo 101, Titulo 17 USC, donde se reconoce que la función es “producir un cierto resultado”.
Si hubiese que aceptar la posición de la Corte de Distrito que sugiere que un programa de computación no es protegible simplemente porque “produciría ciertas funciones pre-asignadas” ningún programa de computación seria protegible bajo el sistema de derechos de autor.
Esto sería contrario a lo querido por el Congreso al proveer protección a los programas de computación, como también sería contradictorio con la doctrina obligatoria emanada del Circuito Noveno.
Entonces, un conjunto de comandos que instruyen a una computadora para producir un resultado esperado puede contener expresión que sea elegible para la protección bajo el sistema de derechos de autor.
Es decir, que una obra original -incluso aquella que su propósito sea una función-se encuentra sujeta a protección bajo el derecho de autor siempre que el autor posee múltiples formas de expresar la idea.
El artículo 102, inciso (b) no niega protección “en forma automática” a los elementos de un programa de computación que son funcionales.
Oracle no reclamó protección en abstracto al respecto de la idea de la estructura organizacional de las funciones de su programa de computación o de sus paquetes/clases/métodos.
Por el contrario, Oracle reclamo por la protección de su “forma particular” de organizar y nombrar a los 37 paquetes de las API de Java.
En la etapa de los argumentos orales Oracle expresó que nunca sostendría que alguien que use el formato de clasificación en “paquete/clases/métodos” violaría los derechos de Oracle.
En absoluto.
Oracle no posee la propiedad de todas las formas posibles de concebir una manera de “organizar”.
Oracle sólo sostuvo que posee la propiedad, y por ello reclamó la protección, de la “forma específica de su expresión”, de nombrar cada uno de los 362 métodos, poniéndolos en 36 clases distintas, y en 20 subclases.
Teniendo en cuenta todo lo expuesto, el Tribunal de Apelaciones del Circuito Federal entendió que la estructura, secuencia y organización era original y creativa, y que el código declarado podía haber sido escrito y organizado en varias formas y aun así lograr obtenerse las mismas funciones [86], por ello concluyó que el artículo 102, inciso (b) no prohíbe a los paquetes de Java de la protección otorgada por el sistema de derechos de autor sólo porque estos a su vez ejecuten “funciones”.
LA INTEROPERABILIDAD ALEGADA POR GOOGLE NO ES RELEVANTE PARA EL ANÁLISIS DE LA PROTECCIÓN BAJO EL SISTEMA DE LOS DERECHOS DE AUTOR DE EE.UU.
La interoperabilidad alegada por Google no es relevante para el análisis de si las API de Java son protegibles o no a la luz del derecho de autor de EE.UU.
La Corte de Distrito calificando a la estructura, secuencia y organización de los paquetes de las API de Java como un “método de operación” o “método para operar” o “sistema para operar”, también dijo que la duplicación o la copia del “comando de estructura” era necesario para garantizar la “interoperabilidad”, diciéndose de que en orden a que al menos parte del código pudiera correr en Android, Google tenía que proveer el mismo sistema de comandos de java.package.Class.method() utilizando los mismos nombres con la misma estructura o taxonomía y con las mismas especificaciones de funcionalidad.
Por ello, el Juez de Distrito concluye que Google replicó aquello que era necesario para lograr un grado de compatibilidad, no más que eso, pero realizando su propia implementación.
Ahora bien, para llegar a esta conclusión el Juez de Distrito se basó en dos casos resueltos por el Tribunal de Apelaciones del Circuito Federal del Circuito Noveno: Sega Enterprises v. Accolade, Inc, 977 F.2d 1510 (9th Cir.1992) y Sony Computer Entertainment, Inc. V. Connectix, Corp., 203 F.3d 596 (9th Cir.2000).
Así interpretó que estas dos decisiones sostuvieron que los procesos de interfaces que son necesarios duplicar con el objeto de lograr compatibilidad son aspectos funcionales que no están protegidos bajo el sistema de derechos de autor de EE.UU. ello conforme a lo dispuesto en el artículo 102, inciso (b), USC Titulo 17.
Veamos que en el caso Sega Enterprises v. Accolade, Inc [87], Sega era un fabricante de consolas de videos juegos, como también de cartuchos de videos juegos que tenían estos últimos una suerte de programas ocultos cuyos elementos eran necesarios para lograr compatibilidad con su consola.
Accolade efectúo ingeniería inversa de los cartuchos de videos juegos de Sega para conocer los requerimientos de compatibilidad, y así poder crear sus propios cartuchos de videos juegos para ser usados en la consola de Sega.
Teniendo en cuenta que en el proceso de descompilación, Accodale efectúo copias intermedias del código objeto de la consola de Sega, y si bien ello fue reconocido como que podría causar infracción, se concluyó que desamblar o descompilar código objeto protegido por las ley de derechos de autor de EE.UU. constituye un uso justo (en inglés “fair use”) en la medida de que dicha descompilación sea la única manera o medio para acceder a aquellos elementos de código que no son protegibles por el derecho de autor y el copista tenga una razón legítima para obtener dicho acceso.
Como se entendió que la empresa Accolade tenía un interés legítimo en fabricar sus propios cartuchos para hacerlos compatibles con la consola de Sega, se reconoció que la copia de código efectuada constituía uso justo.
En el caso Sony Computer Entertainment, Inc. V. Connectix, Corp. [88], el Circuito Noveno se expresó en forma similar, y dijo que la ingeniería inversa y la copia intermedia realizada por el demandado en relación al programa de software de Sony -protegido por la ley de derechos de autor de EE.UU.- con el propósito de obtener acceso a elementos no protegidos del software de Sony constituye uso justo.
Se dijo que el proceso de descompilación era la única forma en que se podía lograr acceso a los elementos no protegidos
El Tribunal de Apelaciones del Circuito Federal menciona en primer lugar, que ambos casos se relacionan con uso justo, y no con la protección bajo derechos de autor de un determinado programa de computación (en inglés “copyrightability”).
En segundo lugar, expresa que utilizar como base los casos de Sony y Sega para revisar el asunto de la protección (en inglés “copyrighability”) en el presente juicio está fuera de contexto y constituye un error.
Si bien reconoce el Tribunal de Apelaciones del Circuito Federal que en ambos casos se reconoció que los programas de software contenían elementos funcionales que no estaban protegidos por la ley de derechos de autor de EE.UU., no podría afirmarse que por ese sólo hecho, es decir, porque que existan elementos funcionales no protegibles en un programa, convierta a todo el programa de computación como no protegible por la ley de derechos de autor de EE.UU.
Por ello el Tribunal de Apelaciones del Circuito Federal expresa su desacuerdo a la sugerencia efectuada por Google de que los casos Sony y Sega hayan creado una “excepción de interoperabilidad” al régimen de derechos de autor del sistema de EE.UU.
Y agrega que para determinar si ciertos aspectos de un supuesto software en infracción no están protegidos bajo la ley de derechos de autor de EE.UU., el foco debe estar puesto en los “factores externos” que influenciaron en las alternativas del creador del producto en supuesta infracción [89].
Por ejemplo, esto podría ser las especificaciones de una computadora sobre la cual un programa de software en particular deseara ejecutarse o los requerimientos de compatibilidad de otros programas con los cuales el programa está diseñado para operar en su conjunto.
Teniendo en cuenta que la protección bajo la ley de derechos de autor se focaliza en las opciones disponibles que tenía su autor al momento de crear el programa de computación, la pregunta relevante en materia de compatibilidad sería si las opciones del creador fueron dictadas o no por la necesidad de asegurar que su programa funcione con los programas existentes de terceros.
En definitiva, si el demandado busca posteriormente hacer interoperable su programa con el programa de la parte actora o demandante, ello no tiene relación con respecto a si el software creado por el demandado tenía alguna limitación de diseño dictada por factores externos [90].
Por ello es la interoperabilidad de Oracle la que importa, y no la de Google, y es la que aplicable en el contexto de protección de derechos.
Y conforme a las evidencias del pleito no surge que cuando Oracle creó los paquetes de las API de Java lo hiciera para obtener requerimientos de compatibilidad de otros programas preexistentes.
De nuevo, el requisito de compatibilidad debe ser analizado al momento del creador no de quién copia (en el caso Google).
Por otro lado, Google sostuvo que los nombres y las declaraciones de las clases y los métodos de Java era la única manera o medio para lograr el grado de interoperabilidad con los programas existentes en el lenguaje Java.
Ahora, conforme las constancias del litigio Google diseño Android para que no sea compatible con la plataforma Java, o específicamente con la máquina virtual de Java (Java virtual machine), por lo tanto, el argumento de la interoperabilidad alegada por Google es al menos confuso.
Entonces, se ha dicho que Google copió los paquetes de Java con la finalidad de que una aplicación escrita en Java pudiera ejecutarse en la plataforma Android, pero no hay evidencia en el juicio que tal aplicación exista, como tampoco se menciona ninguna aplicación de Java, sea antes o después de Android, que pudiera ejecutarse en la plataforma Android.
En realidad, la compatibilidad buscada por Google no era con la plataforma Java o con la máquina virtual de Java (JVM), sino que Google quería capitalizar el hecho de que los desarrolladores ya estaban entrenados y con experiencia en utilizar los paquetes de las API de Java.
En definitiva, el interés de Google estaba en acelerar el proceso de desarrollo aprovechando a Java con su base existente de desarrolladores.
Si bien este objetivo de competitividad podría ser relevante a la hora de analizar el uso justo, concluye el Tribunal de Apelaciones del Circuito Federal que no es relevante para analizar si el código fuente declarado y la estructura, secuencia y organización de los paquetes de Java son protegibles o no por el sistema de derechos de autor de EE.UU.
Por otra parte, en relación al argumento sostenido por Google donde sugirió que Google tenía derecho a duplicar o copiar los API de los paquetes de Java porque ello se había vuelto el estándar efectivo en la industria, dicho argumento es rechazado.
Google no cita al respecto ningún caso que sugiera que la protección bajo los derechos de autor se pierda cuando se convierte en “popular”.
En realidad, Google tuvo la libertad de desarrollar sus propios paquetes de API y en su caso cabildear por su adopción, pero en su lugar, Google escogió copiar el código declarado por Oracle y la estructura, secuencia y organización, y capitalizar a la comunidad de programadores preexistentes quienes ya estaban acostumbrados y entrenados a usar los paquetes de Java.
Por esta razón es que se entendió que el argumento de “estándar de la industria” no tenía relación con el análisis de si el código declarado y la estructura, secuencia y organización era protegible o no bajo la ley de derechos de autor de EE.UU.
USO JUSTO (O USO LEGÍTIMO)
Con relación al “uso justo” el Tribunal de Apelaciones del Circuito Federal en su sentencia del 9 de Mayo de 2014 entendió que conforme a las constancias del pleito no había prueba suficiente en relación a los cuatro factores del uso justo o legítimo (“fair use”) y por lo tanto, no podía tomar una decisión al respecto, razón por la cual, ordenó que se llevara a cabo un segundo juicio para que determinara la pregunta de si el uso realizado por Google en relación al código declarado y a la estructura, secuencia y organización podría ser considerado como “uso justo” (en inglés “fair use”).
En efecto, el Tribunal de Apelaciones del Circuito Federal entendió que existían entre las partes disputas en los hechos en cuanto a cómo Android había sido usado, y a su vez, si las API que Google había copiado tenían o servían para cumplir con la misma función en Android que en Java.
Por otra parte, recuérdese que el Jurado se abstuvo de tratar el asunto de “uso justo”, y también de que, el Juez de Distrito había rechazado ordenar un juicio por este asunto, ya que había entendido que el código declarado y la estructura, secuencia y organización, copiado por Google no era protegible por el derecho de autor de EE.UU.