Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CAPITULO VI RECURSO DE APELACIÓN INTERPUESTO POR ORACLE CONTRA LA SENTENCIA DE LA CORTE DE DISTRITO RELACIONADOS A LA PROTECCIÓN DEL CODIGO FUENTE DECLARADO Y DE SU ESTRUCTURA, SECUENCIA Y ORGANIZACIÓN BAJO EL SISTEMA DE DERECHOS DE AUTOR DE EE.UU #13

Open
ggmarmolalioto opened this issue Feb 22, 2022 · 0 comments
Labels
CAPITULO documentation Improvements or additions to documentation

Comments

@ggmarmolalioto
Copy link
Owner

CAPITULO VI

RECURSO DE APELACIÓN INTERPUESTO POR ORACLE CONTRA LA SENTENCIA DE LA CORTE DE DISTRITO RELACIONADOS A LA PROTECCIÓN DEL CODIGO FUENTE DECLARADO Y DE SU ESTRUCTURA, SECUENCIA Y ORGANIZACIÓN BAJO EL SISTEMA DE DERECHOS DE AUTOR DE EE.UU

El Juez de la Corte de Distrito dijo en su sentencia en relación al código fuente declarado que no importaba lo creativo o imaginativo que éste pudiera ser si sólo existe “una manera de escribirlo”, y, por lo tanto, la doctrina de la fusión (en inglés “merge doctrine”) impediría a cualquiera reclamar derechos exclusivos sobre ello.

Por lo tanto, no puede existir infracción de derechos de autor en la utilización de idénticas declaraciones o código fuente declarado.

Por otro lado, también mencionó la sentencia de primera instancia que el código fuente declarado consiste en nombres y frases cortas que no son protegibles bajo el derecho de autor.

Así mismo, la Corte de Distrito reconoció que la estructura, secuencia y organización de cada una de los paquetes de Java era “creativa” y “original”, pero sin importar ello, sostuvo que dicha estructura, secuencia y organización no era protegible por derechos de autor conforme al artículo 102 inciso (b) del Título 17 USC, ya que constituía una “estructura de comandos para un sistema o un método de operación”.

Conforme la posición de Oracle existe dos axiomas que definen el presente caso:

Axioma 1: El umbral de la ley de derechos de autor de EE.UU. para otorgar protección es “bajo” (Feist Publ´ns, Inc. v. Rural tel. ser. Co -1991). En efecto la ley de derechos de autor protege la “expresión original”, y una obra es “original” si posee al menos un mínimo grado de creatividad. A su vez, Oracle obtuvo la presunción como de “obra original y protegida” mediante la registración de la plataforma Java en la Oficina de Derechos de Autor de EE.UU. Más allá de ello, los paquetes de Java son fácilmente protegibles teniéndose presente que exceden el grado de creatividad exigido por la ley.

Axioma 2: La protección bajo la ley de derechos de autor de EE.UU. se extiende a los programas de computación, de la misma manera que se lo hace para cualquier otra obra literaria. Así entonces, se protege a las obras literarias expresadas en palabras, números u otros símbolos verbales o numéricos. Los programas de computación cumplen con esa definición. La conclusión del Juez de la Corte de Distrito en relación a que existe “un tipo de software” (código fuente declarado) que esta por fuera de estas reglas constituye una violación a ambos principios.

Entonces, teniendo en cuenta estos dos axiomas, el código que Google copió está protegido bajo dos principios independientes:

En primer lugar, el código declarado es protegible porque es “expresivo”. Google admitió en el juicio que copió en forma literal 7000 líneas de código. El código declarado copiado por Google es protegible como cualquier otra obra literaria, ya que Oracle ejerció “creatividad en la selección y organización de sus líneas de instrucción”.

En caso similares, donde se reconoció que había existido distintas alternativas o maneras de obtener el mismo resultado se sostuvo que la estructura de código copiado era protegible.

Por otro lado, cada vez que Oracle desarrolló código -incluso código declarado- se comienza con “una pizarra limpia”. No hay “convenciones de programación ni reglas dictadas por el lenguaje de Java” acerca de lo que el código declarado debería ser.

La decisión de Google de no copiar el código implementado por Oracle, y de si copiar el código declarado por Oracle, no transforma a este último en no protegible. Ningún copista puede excusar su conducta inapropiada al mostrar cuanto de su obra no ha pirateado. Google intenta hacer parecer trivial las 7000 líneas de código que copió.

Ahora lo copiado por Google es lo más importante para los programadores de lo que luego Google parafraseó, que fue su código implementado.

De hecho, los programadores no conocen al código implementado, tampoco les es de interés, todo lo que los programadores saben y necesitan saber para programar o construir sus propias aplicaciones es el código fuente declarado de Oracle.

En segundo lugar, la estructura, secuencia y organización de los paquetes de Java fue reconocida en el juicio como original y creativa, por lo tanto, es protegible bajo la ley de derechos de autor, y tiene protección en dos sentidos:

  • a) porque el código declarado incorporado en ella, es protegible, y a su vez, y

  • b) en forma independiente, porque la misma estructura, secuencia y organización es protegible independientemente que el código declarado incorporado a ella lo sea.

Con lo cual, aún si Google no hubiera copiado el código declarado de Oracle, y si la estructura, secuencia y organización, como lo hizo, de todas formas, también hubiese existido infracción de derechos.

En la construcción de la estructura y organización de los paquetes de Java existieron infinitas opciones para Oracle, y, además de ello, se la construyó de manera tal que los programadores la encontraran atractiva y muy fácil de recordar.

A su vez, Google reconoció que la estructura, secuencia y organización de los 37 paquetes de las API incluidas en Android es sustancialmente la misma que la estructura, secuencia y organización de los 37 paquetes de las API de Java.

Por otro lado, la estructura, secuencia y organización sería igualmente protegible por los derechos de autor, aunque Google no hubiese copiado una sola línea de código. (y más lo sería como en el caso teniendo en cuenta que ha copiado los elementos que la conforman con sus 7000 líneas de código).

En definitiva, los elementos no literales del programa de computación, que incluye la estructura, secuencia, y organización pueden ser protegidos por derechos de autor donde existe una expresión creativa.

Por ello, en el caso, conforme constancias del juicio, Oracle tuvo infinitas opciones para organizar y seleccionar los distintos programas dentro de los paquetes de Java, con lo cual “la idea de cómo organizar cada paquete no se fusiona como su expresión”, ya que como se dijo existieron múltiples formas de poder llevarse a cabo, por ello el artículo 102, inciso b) no es aplicable.

Por lo demás, el razonamiento del Juez de Distrito cuando dice que ni una sola línea de código declarado puede recibir protección bajo derecho de autor, ya que constituyen comandos para llevar a cabo funciones preasignadas, si ello fuese correcto, ningún programa de computación estaría protegido, ya que esa es la definición de programa de computación conforme a la ley, cuando dice “conjunto de declaraciones o instrucciones para ser usadas directa o indirectamente en una computadora con el propósito de llevar a cabo un resultado”.

Entonces, si un programa de computación no es protegible por derechos de autor por la simple razón de que posee el propósito de llevar a cabo funciones preasignadas, ningún programa de computación sería protegible.

De hecho, esto se encuentra en contradicción con lo dispuesto en casos judiciales anteriores, donde se ha mencionado que se reconoce la protección del código fuente aún en los casos que consistan en comandos para llevar a cabo funciones preasignadas.

El Juez de Distrito menciona como aplicable el caso de Lotus Development v. Borland International, Inc.

Ahora ese caso, no tiene relación con el caso en cuestión, ya que el demandado sólo copio un sistema simple de menú de comandos, y no código.

Entonces, en el caso Lotus, se estableció una definición de método de operación muy expansiva que dice “cualquier medio por el cual una persona opera algo”, pero esa decisión no puede ser aplicada más allá de los hechos de ese caso, ya que de lo contrario le quitaría la protección bajo derechos de autor a todos los programas de computación, y ello, iría en contra de lo sancionado por el Congreso de los EE.UU.

En la actualidad ningún Circuito de los EE.UU. adopta la fórmula del caso Lotus.

Por otro lado, en el caso Atari, se encontró infracción aún, cuando no hubo copia de elementos literales del programa de computación.

Atari había copiado la estructura organizacional y secuencial de la función de seguridad de Nintendo. Y se determinó que como los programadores de Nintendo tuvieron varias maneras disponibles para llevar a cabo la función de seguridad, Nintendo ejerció creatividad en su selección.

En relación a la doctrina de la fusión (en inglés “merge doctrine”), la Corte de Distrito se equivoca al aplicar esta doctrina en relación al código declarado cuando menciona que “no importa lo creativo o imaginativo que sea si existe una sóla manera de escribirlo”, y que, por lo tanto, la doctrina de la fusión impide a cualquiera reclamar derechos exclusivos sobre ello.

Ahora, dicha doctrina no es aplicable a ninguna línea individual del código declarado a menos que sus autores originarios (Oracle) hayan tenido disponible “una sola forma o manera” -que no fue el caso- de escribir esas líneas de código, en el caso, de las 7000 líneas de código fuente declarado.

Entonces, como como surge de las constancias del juicio, Oracle tuvo infinidad de opciones para cada una de las líneas individuales y también tuvo una infinidad de opciones en la selección y organización de las 7000 líneas de código que Google copió.

Por ejemplo, el Juez menciona java.lang.Math.max.

Los desarrolladores de Sun Microsystems podrían haberlo llamado “Math.maximun”, “Equations.compare”, “Arith.bigger, “MeasuringStick”, etc.

A su vez, quedó demostrado que “la idea y la expresión no se fusionaron” cuando fue el mismo Juez del Distrito que expresó que los métodos y las clases de Android podrían haber tenido un nombre diferente que los métodos y las clases de Java, y aun así hubieran funcionado igual.

En definitiva, Oracle tuvo infinidad de posibilidades acerca de que métodos incluir y de cómo organizarlos.

De hecho, también ha sido reconocido por el Juez que conceder protección por derechos de autor no hubiese impedido que Android provea las mismas funciones, pero organizadas de una manera diferente, y esto podría haber sido hecho mediante la reorganización de varios métodos dentro de distintos grupos dentro de varias clases y paquetes (aunque incluso se hubiesen usado los mismos nombres).

En este sentido, había muchas formas de agrupar a los métodos y así duplicar el mismo rango de funcionalidades.

De hecho, en unos 100 paquetes de Android Google escribió su propio código declarado, con su propia estructura y organización.

Pero no hizo lo mismo con los 37 paquetes de Java en cuestión.

Entonces, como varias expresiones alternativas existen disponibles, la teoría de la fusión no es aplicable.

Adicionalmente, tanto respecto de las líneas individuales de código declarado o de todo el cuerpo del código declarado, las opciones disponibles son las que poseía el autor de la obra original (Oracle) en el momento de su creación, y no, las opciones que podría haber tenido el copista al momento de copiar.

El Juez del Distrito menciona que para llevar a cabo una determinada función la especificación del método establecida en la declaración o código declarado debe ser idéntica.

Ahora bien, una vez que el autor de una obra original (en el caso Oracle) eligió crear y denominar a un método como “java.lang.Math.max”, los programadores que quieren utilizar el programa pre-escrito de Oracle lógicamente tienen que llamarlo por su nombre.

Ahora, esto no significa que la obra original no pueda ser protegida por el derecho de autor.

Qué es lo que el copista cree que necesita copiar de la obra original para su beneficio, es irrelevante, porque el derecho de autor subsiste desde el momento mismo de creación y perdura conforme a los plazos establecidos en la ley.

Por otro lado, en relación a las “frases cortas” el Juez del Distrito menciona que cada una de las líneas del código declarado en forma aislada no son protegibles.

El Juez para ello invoca una regulación de la Oficina de Derechos de Autor de EE.UU., la cual se refiere a “obras” que estén un tanto vacío de texto. En definitiva, ello quedaría cubierto por el derecho de marcas.

Ahora bien, por el contrario, lo anterior sobre “frases cortas” no elimina de protección al ensamble de 7000 líneas de código.

El error se encuentra en querer diseccionar la obra en forma demasiado minuciosa, poniéndose foco en la línea individual del código, en lugar de ponerlo en el complejo arreglo del cual forma parte.

De hecho, aplicar la teoría de las frases cortas como lo propone el Juez del Distrito, significaría que virtualmente ningún programa de computación estaría protegido.

Por ejemplo, el código fuente declarado en el método de Java en java.security.cert.package es el siguiente:

public abstract void verify (PublicKey key, String sigProvider)
throws CertificateException, NoSuchAlgorithmException,
InvalidKeyException, NoSuchProviderException
SignatureException

O del código fuente declarado en la clase java.nio.channels:

public abstract class DatagramChannel
extends AbstractSelectableChannel
implements ByteChannel, ScatteringByteChannel, GatheringByte
Channel {

Aún en el caso de un “código fuente declarado” más corto que los ejemplos mencionados más arriba, no necesariamente quedarían desprotegidos.

En definitiva, es equivoca la posición del Juez del Distrito en relación a la aplicación de la “teoría de frases cortas”, y, por lo tanto, explica Oracle no es aplicable al presente caso.

@ggmarmolalioto ggmarmolalioto added documentation Improvements or additions to documentation CAPITULO labels Feb 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CAPITULO documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

1 participant