¿Las interfaces y firmas de métodos están protegidas por derechos de autor?

Por ejemplo, ¿es una infracción de derechos de autor si escribo una clase llamada Aleatoria con el mismo propósito y firmas de método que la clase .Net System.Random de Microsoft? ¿Hace alguna diferencia en qué idioma está escrito? En este caso, quiero escribir una clase aleatoria para usar en ActionScript, que carece de una clase PRNG sembrada incorporada.

Si alguien tiene buenos enlaces o sugerencias de referencia para comprender qué aspectos del software están protegidos, también es genial. Y sí, sé que este no es el lugar para el asesoramiento legal "real". Si alguien va a la corte señalando un tablero de mensajes público como precedencia, lástima de ellos.

Creo que mirar la relación entre Mono y Dotnet responde a esta pregunta. El equipo Mono puede hacer uso de las definiciones de métodos o la interfaz pública, pero tienen que volver a implementar los elementos internos. Sin embargo, el caso de Android v Oracle presenta algunos otros puntos que hacen que esta distinción obvia sea un poco más borrosa. En el caso de AvO, la mayoría de los puntos que se llevan a los tribunales son patentes relacionadas con la VM, las interfaces de la biblioteca no han sido un punto de contención. El único código que se ha resaltado son ejemplos en los que parece que hasta cierto punto se copiaron los elementos internos.

Hubo una pregunta similar sobre los esquemas de bases de datos: ¿ Copiar el esquema de base de datos de un competidor? Respondí que copiar todo el esquema probablemente sería una infracción de derechos de autor, dependiendo de la escala de la copia, apreciada por un juez.

Incluso si su pregunta es similar, responderé todo lo contrario: puede copiar firmas de métodos. ¿Por qué?

De hecho, las firmas de métodos provienen del sentido común.

• En primer lugar, si tomamos un ejemplo extremo, Microsoft no puede proteger los derechos de autor del nombreRandom y demandar a todos los que usarán la palabra Randomen cualquier aplicación.

• En segundo lugar, ¿qué estás tratando de hacer exactamente? ¿Reimplementar .NET Framework? ¿Por qué? No hay necesidad de reinventar la rueda . Si sabe cómo hacerlo mejor, más intuitivo, etc., es probable que obtenga mejores nombres de clases y métodos, una mejor organización, etc. Si intenta copiar la estructura de .NET Framework para portarlo a otro idioma , entonces no eres un competidor directo de Microsoft, por lo que no tienen motivos serios para demandarlo (dicho esto, lo demandarán si copia el código fuente en sí). En realidad, incluso se beneficiarán de usted: copiar dicha estructura a otros marcos no solo mostrará el éxito de .NET Framework, sino que también facilitará que los desarrolladores de .NET trabajen con otros idiomas, y que los desarrolladores de otros idiomas aprendan .RED.

• En tercer lugar, tienen cosas más serias que hacer que demandar a todos los que copien los nombres de los métodos y clases de .NET Framework.

Ahora, si su intención es copiar todo .NET Framework y hacer un producto que será utilizado por muchos desarrolladores, consulte a un abogado antes de tomar riesgos.

Un ejemplo:

Estaba totalmente descontento con la vergonzosa limitación de 259 caracteres en las rutas de archivos en .NET Framework y la imposibilidad de usar transacciones de código a nivel de archivo. Así que implementé mi propia Fileclase con los métodos que funcionarían como se esperaba para cualquier ruta, no solo los pequeños y pequeños, e implementaría transacciones. En la primera versión, decidí clonar los nombres de métodos Filey Directoryclases . ¿Me demandaría Microsoft por hacer eso? Lo dudo.

En todos los casos, en la segunda versión Vine con una nueva sintaxis, new File(string fileName)que me parece mucho más intuitivo para mí . Clonar nombres de métodos a veces es útil, pero debe tener una buena razón para hacerlo.

La protección de los derechos de autor protege la "expresión artística" de una obra, no la forma técnica (para citar wikipedia ).

La protección de los derechos de autor no protege los hechos .

Entonces la pregunta es, ¿es una API o interfaz un "hecho" o una expresión artística? Para API simples que son solo una lista de formas de obtener números aleatorios y los diferentes tipos de números aleatorios, la API es probablemente más como un hecho. Pero, pude ver que hay una interfaz muy sofisticada (ya sabes, las que miras por un minuto y luego dices "¡Ahh! Eso es impresionante") podría considerarse una "expresión artística" digna de protección.

Aquí hay un artículo reciente sobre Oracle y Google peleando por derechos de autor de API sobre este mismo tema que se debate en los tribunales (de EE. UU.).

No soy abogado, y esta publicación no debe interpretarse como asesoramiento legal. Ni siquiera puedo escribir renuncias muy bien.

Puede tomar los aspectos puramente funcionales, pero no puede tomar los aspectos expresivos. El nombre de la clase, los nombres de los métodos y las firmas son puramente funcionales. Los necesitas para interactuar. Los nombres de los parámetros y las macros de encabezado pueden considerarse expresivos. Por ejemplo, en su caso antimonopolio de Windows, Microsoft argumentó que nada impedía que un competidor replicara las API de Windows y creara su propia plataforma en la que se ejecutarían las aplicaciones de Windows.