接口和方法签名是否受版权保护？

例如，如果我编写一个名为Random的类，其目的和方法签名与Microsoft的.Net System.Random类完全相同，是否会侵犯版权？使用哪种语言会有所不同吗？在这种情况下，我想编写一个在ActionScript中使用的Random类，该类缺少内置的种子PRNG类。

如果有人拥有良好的链接或参考建议以了解软件的哪些方面受到保护，那也很好。是的，我知道这不是“真正的”法律建议的地方。如果有人去法院指责公共留言板是最重要的事情，那就可耻了。

我相信查看Mono和Dotnet之间的关系可以回答这个问题。Mono团队可以使用方法定义或公共接口，但是他们必须重新实现内部结构。但是，Android v Oracle案提出了其他几点，使这一明显的区别变得有些模糊。在AvO案件中，大多数提起诉讼的是与VM相关的专利，但库接口并不是争论的焦点。突出显示的唯一代码是一些示例，在这些示例中似乎可以复制内部代码。

关于数据库方案，存在类似的问题：复制竞争对手的数据库架构？我在那儿回答说，复制整个架构可能会侵犯版权，这取决于复制的规模，法官对此表示赞赏。

即使您的问题相似，我也会回答相反的问题：您可以复制方法签名。为什么？

实际上，方法签名来自常识。

• 首先，如果举一个极端的例子，微软将无法对该名称进行版权保护Random，也不会起诉Random任何将在任何应用程序中使用该词的人。

• 其次，您到底想做什么？重新实现.NET Framework？为什么？无需重新发明轮子。如果您知道如何使其变得更好，更直观等，那么您将可能会得到更好的类和方法名称，更好的组织等。如果尝试复制.NET Framework的结构以将其移植到另一个语言，那么您不是Microsoft的直接竞争对手，因此他们没有严肃的理由起诉您（也就是说，如果您复制源代码本身，他们将起诉您）。实际上，他们甚至会从您那里受益：将这种结构复制到其他框架中不仅会展示.NET Framework的成功，而且还将使.NET开发人员更轻松地与其他语言一起使用，并且使其他语言的开发人员也可以学习。 。净。

• 第三，与起诉要复制.NET Framework方法和类的名称的所有人相比，他们要做的事情更为严肃。

现在，如果您打算复制整个.NET Framework并制作将被许多开发人员使用的产品，请在冒险之前咨询律师。

一个例子：

我对 .NET Framework中文件路径的259个字符限制的不足以及无法在文件级别使用代码事务感到完全不满意。因此，我实现了自己的File类，该类的方法可以在任何路径上都能正常工作，而不仅仅是微小的短路径，并且可以实现事务。在第一个版本中，我决定在File和Directory类中克隆方法的名称。微软会起诉我吗？我对此表示怀疑。

在所有情况下，在第二版中，我都使用了新的语法，对我来说new File(string fileName)，它更直观。克隆方法名称有时很有用，但是您必须有充分的理由这样做。

版权保护保护的是作品的“艺术表达”，而不是技术形式（引用Wikipedia）。

版权保护不能保护事实。

因此问题就来了，API或接口是“事实”还是艺术表达？对于仅是获取随机数和不同种类的随机数的方法列表的简单API，API可能更像一个事实。但是，我可以看到有一个非常复杂的界面（您知道，您凝视了一下，然后说“啊！这真令人印象深刻。”）可以被认为是值得保护的“艺术表达”。

这是一篇有关Oracle和Google争夺API版权的最新文章，有关这一问题正在美国法院进行辩论。

我不是律师，因此此职位不应解释为法律意见。我什至不能很好地写免责声明。

您可以采用纯粹的功能性方面，但不能采用表现性的方面。类名，方法名和签名纯粹是功能。您需要它们进行互操作。参数名称和标头宏可以被认为是可表达的。例如，在Windows反托拉斯案中，微软认为，没有任何因素可以阻止竞争对手复制Windows API并创建自己的运行Windows应用程序的平台。