stringtranslate.com

Estructura, secuencia y organización

Estructura, secuencia y organización ( SSO ) es un término utilizado en los Estados Unidos para definir una base para comparar un trabajo de software con otro con el fin de determinar si se ha producido una copia que infrinja los derechos de autor, incluso cuando el segundo trabajo no sea una copia literal del primero. El término se introdujo en el caso de Whelan v. Jaslow en 1986. [1] El método de comparación de la SSO de dos productos de software ha evolucionado desde entonces en un intento de evitar los extremos de sobreprotección y subprotección, ambos considerados como desalentadores de la innovación. [2] Más recientemente, el concepto se ha utilizado en Oracle America, Inc. v. Google, Inc. [3]

Whelan contra Jaslow

Whelan Assocs., Inc. v. Jaslow Dental Laboratory, Inc. fue un caso histórico en la definición de los principios que se aplicaban a los derechos de autor del software de computadora. [4] Whelan había desarrollado un software para Jaslow para gestionar las operaciones de un laboratorio dental, y más tarde lo llevó al mercado bajo el nombre comercial Dentalab . Jaslow se dedicó a vender el software Dentalab . [5] Más tarde formó una nueva empresa llamada Dentcom y escribió un programa en un lenguaje de computadora diferente pero con una funcionalidad similar al que llamó Dentlab , comercializándolo como un sucesor de Dentalab . Whelan presentó una demanda en un tribunal federal de Pensilvania alegando que el software Dentlab violaba los derechos de autor de Whelan en el software Dentalab . Whelan ganó el caso y recibió una indemnización por daños y perjuicios sobre la base de que Dentlab tenía una estructura y una organización general sustancialmente similares. [6]

El fallo del tribunal de distrito en Whelan se basó en la doctrina establecida de que incluso cuando las partes componentes de una obra no pueden ser objeto de derechos de autor, la estructura y la organización de una obra pueden serlo. [7] El tribunal también se apoyó en el caso SAS Inst. Inc. v. S&H Computer Sys. Inc. de 1985 en el que se había determinado que los derechos de autor protegían los detalles organizativos y estructurales, no solo líneas específicas de código fuente u objeto. [fn 1] [8] La secuencia, estructura y organización (SSO) en este caso se definió como "la manera en que el programa opera, controla y regula la computadora al recibir, ensamblar, calcular, retener, correlacionar y producir información útil". [1] SSO se refiere a elementos no literales de programas informáticos que incluyen "formatos de entrada de datos, estructuras de archivos, diseño, organización y flujo del código, salidas de pantalla o interfaces de usuario, y el flujo y secuencia de las pantallas". [9] Sin embargo, el caso SAS Inst. Inc. V. S&H Computer Sys. Inc. demostró que los derechos de autor pueden existir en obras derivadas del código fuente desarrollado con fondos públicos en el dominio público [10] en lugar de abordar la cuestión del SSO.

Jaslow apeló la decisión. El Tribunal de Apelaciones del Tercer Circuito señaló que los programas informáticos son obras literarias según la legislación estadounidense. [11] El tribunal razonó que en el caso de las obras literarias, un elemento no literal está protegido en la medida en que sea una expresión de una idea y no la idea en sí. Por analogía, el propósito o la función de una obra de software sería la "idea" de la obra, mientras que todo lo que no sea necesario para ese propósito o función sería parte de la expresión de la idea. La expresión estaría protegida, aunque el propósito o la función básicos no lo estarían. [5] Sobre esta base, el Tribunal de Apelaciones confirmó la decisión del tribunal de distrito sobre la violación de los derechos de autor debido a la similitud de SSO. [12]

Adopción temprana y críticas

Durante los siguientes años, la mayoría de los tribunales de circuito, aunque no todos, aceptaron la decisión Whelan sobre SSO de una forma u otra. [13] Esto dio lugar a un período de protección estricta para el software, ya que casi todo lo que no fuera el propósito general de una obra de software estaría protegido. La única excepción era cuando la funcionalidad solo podía lograrse de un número muy pequeño de formas. En estos casos no podía haber protección debido a la doctrina de la fusión , que se aplica cuando la expresión y la idea están inextricablemente fusionadas. [2]

En un caso, un tribunal determinó que un acusado había infringido el derecho a preparar un trabajo derivado al copiar la secuencia, la estructura y la organización de los formatos de archivo, la pantalla, los informes y los códigos de transacción del demandante, a pesar de que existían campos de datos diferentes. [14] En 1986, la sentencia en Broderbund Software, Inc. contra Unison World, Inc. pareció impedir que los desarrolladores de software comercializaran productos con las mismas interfaces de usuario o interfaces de usuario similares, independientemente de si había algo en común en el código subyacente. [13] En el caso de 1990 de Lotus contra Paperback, el Tribunal de Distrito de los Estados Unidos para Massachusetts decidió que el software VP-Planner de Paperback violaba los derechos de autor del programa de hoja de cálculo 1-2-3 de Lotus, ya que tenía la misma interfaz de usuario, a pesar de que el código subyacente era completamente diferente. [15]

Una crítica técnica a Whelan es que no distingue entre la secuencia en la que se presentan las instrucciones en el texto de un programa y la secuencia en la que se ejecutan las instrucciones, es decir, el comportamiento del programa. Tanto los aspectos textuales como los de comportamiento tienen su propio SSO, pero un programador consideraría que el SSO textual es relativamente poco importante. [16] Un punto relacionado es que, aunque el texto de un programa informático puede ser una "obra original de autoría", protegida por las leyes de derechos de autor, los algoritmos y diseños que incorpora el programa pueden considerarse mejor como "procesos, procedimientos, sistemas, métodos de operación", que están explícitamente excluidos de la protección de los derechos de autor, aunque pueden ser protegidos por patentes. [17] Sin embargo, la distinción entre el SSO del código, que está protegido por derechos de autor, y el protocolo o algoritmo, que es patentable, es extremadamente difícil de mantener. [18]

La sentencia Whelan ha sido criticada por ser "peligrosamente amplia". Al decir que el propósito del programa era ayudar a la operación de un laboratorio dental, y que todo lo que no fuera esencial para ese propósito era una expresión, dejó abierta una amplia gama de funciones que podrían considerarse "no esenciales" y, por lo tanto, sujetas a protección. [19] En el caso de 1988 Healthcare Affiliated Services, Inc. v. Lippany, el tribunal adoptó una posición más acorde con el concepto de fusión de idea-expresión, diciendo que la elección del demandado del alcance, las variables a utilizar y otros aspectos de lo que haría su software no constituían la SSO. [20] En 1987, el Tribunal de Apelaciones del Quinto Circuito rechazó la extensión de la protección de los derechos de autor a los elementos no literales de los programas informáticos en el caso de Plains Cotton Cooperative Ass'n v. Goodpasture Computer Serv . El tribunal sostuvo que los formatos de entrada eran ideas en lugar de expresiones y se negó a extender la protección a estos formatos. El tribunal dijo: "Nos negamos a aceptar Whelan ". [13]

Computer Associates contra Altai

En el caso Computer Associates Int. Inc. v. Altai Inc. de 1992, el Tribunal de Apelaciones del Segundo Circuito coincidió con la conclusión de Whelan de que la estructura, secuencia y organización de un programa podrían estar protegidas por derechos de autor cuando fuera apropiado. [21] Sin embargo, el tribunal continuó diciendo: "Como ya hemos señalado, la función o propósito último de un programa de computadora es el resultado compuesto de subrutinas que interactúan. Dado que cada subrutina es en sí misma un programa y, por lo tanto, puede decirse que tiene su propia 'idea', la formulación general de Whelan de que el propósito general de un programa equivale a la idea del programa es descriptivamente inadecuada". [22]

El Segundo Circuito introdujo la prueba de tres pasos de Abstracción-Filtración-Comparación , y varios otros circuitos adoptaron posteriormente esta prueba. En el paso de abstracción, el tribunal identifica similitudes a partir del objeto y el código fuente y avanza hacia niveles superiores de abstracción. En el paso de filtración se descartan todas las similitudes legítimas. [23] Los elementos eliminados en este paso incluyen interpretaciones expresivas obvias de ideas generales, elementos dictados por la eficiencia o consideraciones externas, elementos del dominio público y estándares de la industria. [24] En el paso de comparación, el tribunal decide si existe suficiente similitud entre los elementos restantes para constituir una infracción y, de ser así, la gravedad de la infracción. [23]

Un efecto del caso Altai puede haber sido que las empresas que pensaban que estaban protegidas por Whelan y, por lo tanto, no habían presentado solicitudes de patente, ahora se vieron expuestas. [25] El caso Altai puede haber ido demasiado lejos, en efecto eliminando la protección de todos los elementos excepto los literales de un programa y, por lo tanto, conduciendo a una subprotección. Conscientes de este riesgo, muchos tribunales que siguieron el fallo de Altai parecen haber realizado en la práctica menos filtración de la que exigía la prueba. [2] Sin embargo, la mayoría de los circuitos han aceptado Altai en lugar de Whelan . [26]

Decisiones posteriores

Tanto el código como la apariencia de un producto de software tienen estructura, secuencia y organización. Técnicamente, existe poca o ninguna conexión entre ambos. La misma apariencia puede ser creada por productos de software completamente diferentes, y dos productos de software internamente muy similares pueden presentar una apariencia y una apariencia muy diferentes. Sin embargo, los tribunales han intentado mantener estándares y pruebas comunes para ambos tipos de SSO. [27]

Tras la sentencia Broderbund de 1986 , Lotus Development Corporation demandó a dos proveedores de programas de hojas de cálculo de la competencia por copiar la apariencia de su programa de hojas de cálculo Lotus 1-2-3 , y Apple Computer demandó a Microsoft y Hewlett-Packard por copiar el uso de iconos, menús desplegables y un dispositivo de puntero del ratón del sistema operativo Macintosh . Ambas empresas recibieron críticas, ya que elementos clave de su apariencia habían sido introducidos anteriormente por VisiCalc y Xerox . Un fallo de un tribunal federal de 1992 en contra de Apple rechazó en gran medida la idea de que la ley de derechos de autor pudiera proteger la apariencia. El caso Lotus llegó a la Corte Suprema, que no pudo llegar a una decisión, confirmando así por defecto la declaración de 1995 del tribunal inferior de que las palabras y los comandos utilizados para manipular la hoja de cálculo eran un "método de operación", que no está sujeto a derechos de autor. [28]

Sólo la ley de patentes puede proteger el comportamiento de un programa informático. Los competidores pueden crear programas que proporcionen esencialmente la misma funcionalidad que un programa protegido, siempre que no copien el código. La tendencia ha sido que los tribunales digan que, incluso si hay similitudes no literales con SSO, debe haber prueba de copia. Algunas decisiones judiciales relevantes permiten la ingeniería inversa para descubrir ideas que no están sujetas a derechos de autor dentro de un programa protegido. Las ideas se pueden implementar en un programa competidor siempre que los desarrolladores no copien la expresión original. [29] Con un enfoque de diseño de sala limpia , un equipo de ingenieros deriva una especificación funcional del código original y luego un segundo equipo utiliza esa especificación para diseñar y construir el nuevo código. Esto fue probado a mediados de la década de 1980 por un equipo de Phoenix Technologies para producir un BIOS funcionalmente equivalente al del IBM Personal Computer sin infringir los derechos de autor de IBM. [30]

En agosto de 2010, Oracle Corporation inició una demanda contra Google alegando una combinación de violaciones de patentes y derechos de autor relacionadas con la implementación por parte de Google del lenguaje de programación Java en el sistema operativo Android de Google . El 7 de mayo de 2012, un jurado decidió que Google había infringido los derechos de autor de SSO de 37 paquetes de interfaz de programación de aplicaciones (API) Java, pero no pudo decidir si esto era un uso legítimo. [31] El juez pidió a Google y Oracle que proporcionaran más detalles de sus posiciones sobre si una API o un lenguaje de programación como Java pueden estar sujetos a derechos de autor. También pidió a ambas partes que comentaran una sentencia del Tribunal de Justicia de la Unión Europea en un caso similar que encontró que "Ni la funcionalidad de un programa de computadora ni el lenguaje de programación y el formato de los archivos de datos utilizados en un programa de computadora para explotar algunas de sus funciones constituyen una forma de expresión. En consecuencia, no gozan de protección de derechos de autor". [32] El 31 de mayo de 2012, el juez dictaminó que "siempre que el código específico utilizado para implementar un método sea diferente, cualquiera es libre, bajo la Ley de Derechos de Autor, de escribir su propio código para llevar a cabo exactamente la misma función o especificación de cualquier método utilizado en la API de Java". [33]

Al revisar el historial del caso Oracle v. Google , el tribunal señaló:

... el resumen anterior del desarrollo de la ley revela una trayectoria en la que el entusiasmo por la protección de la "estructura, secuencia y organización" alcanzó su punto máximo en la década de 1980, más notablemente en la decisión Whelan del Tercer Circuito . Esa frase no ha sido reutilizada por el Noveno Circuito desde Johnson Controls en 1989, una decisión que confirmó la medida cautelar. Desde entonces, la tendencia de las decisiones sobre derechos de autor ha sido más cautelosa. Esta tendencia ha sido impulsada por la fidelidad a la Sección 102(b) y el reconocimiento del peligro de conferir un monopolio por derechos de autor sobre lo que el Congreso advirtió expresamente que debería conferirse solo por patente. Esto no quiere decir que la infracción de la estructura, secuencia y organización sea letra muerta. Al contrario, no es letra muerta. Significa decir que el enfoque de Whelan ha dado paso al enfoque de Computer Associates , incluso en nuestro propio circuito. Véase Sega Enters., Ltd. contra Accolade, Inc. , 977 F.2d 1510, 1525 (9th Cir. 1992); Apple Computer, Inc. contra Microsoft Corp. , 35 F.3d 1435, 1445 (9th Cir. 1994). [34]

Referencias

Notas
  1. ^ El software está escrito en código fuente , una colección de instrucciones escritas en un lenguaje de programación legible para humanos. En muchos lenguajes, un compilador traduce esto en código objeto , donde las instrucciones están en un formato que la computadora puede ejecutar. La copia del código fuente se puede disfrazar de manera burda cambiando los nombres de los procedimientos y las variables. Esta forma de disfraz será visible inmediatamente cuando se compare el código objeto, ya que el código objeto será el mismo.
Citas
  1. ^ desde Kappel 1991, pág. 699.
  2. ^ abc Abramson 2001, pág. 57.
  3. ^ Lee 2012.
  4. ^ Graham 1999, pág. 88.
  5. ^ desde Kappel 1991, pág. 704.
  6. ^ Graham 1999, pág. 89.
  7. ^ Hamilton y Sabety 1997, pág. 241.
  8. ^ Epstein 2006, págs. 11-27.
  9. ^ Scott 2006, pág. 5-56.
  10. ^ S & H COMPUTER SYSTEMS contra SAS Institute, Inc., 568 F. Supp. 416 - Tribunal de distrito, Maryland, Tennessee, 1983
  11. ^ Hansen 2006, pág. 170.
  12. ^ Graham 1999, pág. 91.
  13. ^ abc Kappel 1991, pág. 705.
  14. ^ Stapleton 2002, pág. 9.6.
  15. ^ Davidson 1997, pág. 115.
  16. ^ Galler 1995, pág. 87.
  17. ^ Hansen 2006, pág. 196.
  18. ^ Granstrand 2003, pág. 407.
  19. ^ Kappel 1991, pág. 708.
  20. ^ Scott 2006, págs. 5-57.
  21. ^ Takeyama, Gordon y Towse 2005, pág. 11.
  22. ^ Hamilton y Sabety 1997, pág. 250.
  23. ^ desde Abramson 2001, págs. 49-50.
  24. ^ Davidson 1997, pág. 116.
  25. ^ Graham 1999, pág. 92.
  26. ^ Epstein 2006, págs. 11-26.
  27. ^ Epstein 2006, págs. 11-17.
  28. ^ Overbeck y Belmas 2011, pág. 270-271.
  29. ^ Yusuf 2008, págs. 51–52.
  30. ^ Schwartz 2001.
  31. ^ Retti 2012.
  32. ^ Rey y Farber 2012.
  33. ^ Mulin 2012.
  34. ^ Alsup 2012.
Fuentes