Les interfaces et les signatures de méthode sont-elles protégées par le droit d'auteur?

Par exemple, est-ce une violation du droit d'auteur si j'écris une classe appelée Random avec exactement les mêmes signatures de but et de méthode que la classe .Net System.Random de Microsoft? Cela fait-il une différence dans la langue dans laquelle il est écrit? Dans ce cas, je veux écrire une classe Random à utiliser dans ActionScript, qui manque d'une classe PRNG prédéfinie intégrée.

Si quelqu'un a de bons liens ou des suggestions de référence pour comprendre quels aspects du logiciel sont protégés, c'est super aussi. Et oui, je sais que ce n'est pas l'endroit pour de "vrais" conseils juridiques. Si quelqu'un va au tribunal en désignant un babillard public comme une priorité - honte à eux.

Je crois que regarder la relation entre Mono et Dotnet répond à cette question. L'équipe Mono peut utiliser les définitions de méthode ou l'interface publique mais elle doit réimplémenter les internes. Cependant, le cas Android v Oracle soulève quelques autres points qui rendent cette distinction évidente un peu plus floue. Dans le cas d'AvO, la plupart des points portés devant les tribunaux sont des brevets liés à la machine virtuelle, les interfaces de bibliothèque n'ont pas été un sujet de controverse. Le seul code qui a été mis en évidence est des exemples où il semble que dans une certaine mesure, les éléments internes ont été copiés.

Il y avait une question similaire à propos des schémas de base de données: copier le schéma de base de données d'un concurrent? J'y ai répondu que la copie de l'ensemble du schéma constituerait probablement une violation du droit d'auteur, selon l'ampleur de la copie, appréciée par un juge.

Même si votre question est similaire, je répondrai tout à fait le contraire: vous pouvez copier des signatures de méthode. Pourquoi?

En fait, les signatures de méthode proviennent du bon sens.

• Premièrement, si nous prenons un exemple extrême, Microsoft ne peut pas protéger les droits d'auteur du nomRandom et poursuivre tous ceux qui utiliseront le mot Randomdans n'importe quelle application.

• Deuxièmement, qu'essayez-vous de faire exactement? Réimplémenter .NET Framework? Pourquoi? Il n'est pas nécessaire de réinventer la roue . Si vous savez comment le rendre meilleur, plus intuitif, etc., il y a de fortes chances que vous arriviez avec de meilleurs noms de classes et de méthodes, une meilleure organisation, etc. Si vous essayez de copier la structure de .NET Framework pour la porter sur une autre langue , alors vous n'êtes pas un concurrent direct de Microsoft, ils n'ont donc aucune raison sérieuse de vous poursuivre (ceci étant dit, ils vous poursuivront si vous copiez le code source lui-même). En fait, ils bénéficieront même de vous: la copie d'une telle structure dans d'autres frameworks montrera non seulement le succès de .NET Framework, mais facilitera également le travail des développeurs .NET avec d'autres langages et les développeurs d'autres langages pour apprendre .NET.

• Troisièmement, ils ont des choses plus sérieuses à faire que de poursuivre tous ceux qui copieront les noms des méthodes et des classes de .NET Framework.

Maintenant, si votre intention est de copier l'intégralité du .NET Framework et de créer un produit qui sera utilisé par de nombreux développeurs, consultez un avocat avant de prendre des risques.

Un exemple:

J'étais totalement mécontent de la limitation honteuse de 259 caractères dans les chemins de fichiers dans .NET Framework et de l'impossibilité d'utiliser les transactions de code au niveau des fichiers. J'ai donc implémenté ma propre Fileclasse avec les méthodes qui fonctionneraient comme prévu pour n'importe quel chemin, pas seulement les plus petites, et implémenter les transactions. Dans la première version, j'ai décidé de cloner les noms des méthodes Fileet des Directoryclasses . Microsoft me poursuivrait-il pour cela? J'en doute.

Dans tous les cas, dans la deuxième version, je suis venu avec une nouvelle syntaxe new File(string fileName), que je trouve beaucoup plus intuitive pour moi . Le clonage des noms de méthodes est parfois utile, mais vous devez avoir une bonne raison de le faire.

La protection du droit d'auteur protège "l'expression artistique" d'une œuvre, et non la forme technique (pour citer wikipedia ).

La protection du droit d'auteur ne protège pas les faits .

La question devient donc: une API ou une interface est-elle un "fait" ou une expression artistique? Pour les API simples qui ne sont qu'une liste de façons d'obtenir des nombres aléatoires et les différents types de nombres aléatoires, l'API ressemble probablement plus à un fait. Mais, je pouvais voir qu'il y avait une interface très sophistiquée (vous savez, celles que vous regardez pendant une minute, puis dites "Ahh! C'est impressionnant.")) Pourrait être considérée comme une "expression artistique" digne de protection.

Voici un article récent sur Oracle et Google se battant pour le droit d' auteur sur l'API à propos de ce problème en cours de discussion devant les tribunaux (américains).

Je ne suis pas avocat et ce billet ne doit pas être interprété comme un avis juridique. Je ne peux même pas très bien écrire des clauses de non-responsabilité.

Vous pouvez prendre les aspects purement fonctionnels, mais vous ne pouvez pas prendre les aspects expressifs. Le nom de classe, les noms de méthode et les signatures sont purement fonctionnels. Vous en avez besoin pour interagir. Les noms de paramètres et les macros d'en-tête peuvent être considérés comme expressifs. Par exemple, dans son affaire antitrust Windows, Microsoft a fait valoir que rien n'empêchait un concurrent de répliquer les API Windows et de créer sa propre plate-forme sur laquelle les applications Windows s'exécuteraient.