As interfaces e assinaturas de método estão protegidas por direitos autorais?

Por exemplo, é uma violação de direitos autorais se eu escrever uma classe chamada Random com exatamente as mesmas assinaturas de finalidade e método da classe .Net System.Random da Microsoft? Faz diferença em que idioma está escrito? Nesse caso, quero escrever uma classe Random para uso no ActionScript, que não possui uma classe PRNG inicial incorporada.

Se alguém tiver bons links ou sugestões de referência para entender quais aspectos do software estão protegidos, isso também é ótimo. E sim, eu sei que este não é o lugar para aconselhamento jurídico "real". Se alguém for a tribunal apontando para um quadro de mensagens público como precedência - que vergonha.

Acredito que olhar para o relacionamento entre Mono e Dotnet responda a essa pergunta. A equipe Mono pode fazer uso das definições de método ou da interface pública, mas precisa reimplementar os internos. No entanto, o caso Android v Oracle traz alguns outros pontos que tornam essa distinção óbvia um pouco mais embaçada. No caso do AvO, a maioria dos pontos que estão sendo levados a tribunal são patentes relacionadas à VM, as interfaces da biblioteca não foram um ponto de discórdia. O único código que foi destacado são exemplos em que, até certo ponto, parece que os internos foram copiados.

Havia uma pergunta semelhante sobre os esquemas de banco de dados: Copiando o esquema de banco de dados de um concorrente? Respondi lá que copiar todo o esquema provavelmente seria uma violação de direitos autorais, dependendo da escala da cópia, apreciada por um juiz.

Mesmo que sua pergunta seja semelhante, responderei exatamente o contrário: você pode copiar assinaturas de métodos. Por quê?

De fato, as assinaturas de métodos vêm do senso comum.

• Em primeiro lugar, se dermos um exemplo extremo, a Microsoft não podeRandom criar copyright do nome e processar todos que usarem a palavra Randomem qualquer aplicativo.

• Em segundo lugar, o que você está tentando fazer exatamente? Reimplementando o .NET Framework? Por quê? Não há necessidade de reinventar a roda . Se você sabe como torná-lo melhor, mais intuitivo etc., é provável que você venha com melhores nomes de classes e métodos, uma organização melhor etc. Se você tentar copiar a estrutura do .NET Framework para portá-la para outra idioma , então você não é um concorrente direto da Microsoft, portanto, eles não têm motivos sérios para processá-lo (isto dito, eles o processarão se você copiar o código-fonte). Na verdade, eles até se beneficiarão com você: copiar essa estrutura para outras estruturas não apenas mostrará o sucesso do .NET Framework, mas também facilitará o trabalho dos desenvolvedores do .NET com outros idiomas e os desenvolvedores de outros idiomas para aprender. .INTERNET.

• Em terceiro lugar, eles têm coisas mais sérias para fazer do que processar todos que copiarem os nomes dos métodos e classes do .NET Framework.

Agora, se sua intenção é copiar todo o .NET Framework e criar um produto que será usado por muitos desenvolvedores, consulte um advogado antes de correr riscos.

Um exemplo:

Fiquei totalmente descontente com a limitação de vergonha de 259 caracteres nos caminhos de arquivo no .NET Framework e a incapacidade de usar transações de código no nível do arquivo. Portanto, implementei minha própria Fileclasse com os métodos que funcionariam conforme o esperado para qualquer caminho, não apenas os pequenos e pequenos, e implemento transações. Na primeira versão, decidi clonar os nomes dos métodos em Filee Directoryclasses . A Microsoft me processaria por fazer isso? Eu duvido.

Em todos os casos, na segunda versão, eu vim com uma nova sintaxe new File(string fileName), que acho muito mais intuitiva para mim . Às vezes, a clonagem de nomes de métodos é útil, mas você deve ter um bom motivo para fazê-lo.

A proteção de direitos autorais protege a "expressão artística" de uma obra, não a forma técnica (para citar a Wikipedia ).

A proteção de direitos autorais não protege fatos .

Então, a pergunta se torna: uma API ou interface é um "fato" ou uma expressão artística? Para APIs simples que são apenas uma lista de maneiras de obter números aleatórios e os diferentes tipos de números aleatórios, a API provavelmente é mais um fato. Mas pude ver que existe uma interface muito sofisticada (você sabe, as que você olha por um minuto e depois diz "Ahh! Isso é impressionante".) Poderia ser considerada uma "expressão artística" digna de proteção.

Aqui está um artigo recente sobre Oracle e Google brigando por direitos autorais de API sobre esse mesmo assunto sendo debatido nos tribunais (EUA).

Não sou advogado e este post não deve ser interpretado como aconselhamento jurídico. Eu não consigo nem escrever muito bem.

Você pode assumir os aspectos puramente funcionais, mas não os aspectos expressivos. O nome da classe, os nomes dos métodos e as assinaturas são puramente funcionais. Você precisa deles para interoperar. Nomes de parâmetros e macros de cabeçalho podem ser considerados expressivos. Por exemplo, em seu caso antitruste do Windows, a Microsoft argumentou que nada impedia um concorrente de replicar APIs do Windows e criar sua própria plataforma na qual os aplicativos Windows seriam executados.