新闻关于谷歌和甲骨文API侵权案

Posted 2021-06-23 隔壁王书

2021 年 4 月 5 日，美国最高法院就 Oracle 起诉 Google 知识产权侵权案作出了判决，这场两大科技巨头之间长达十几年的官司终于“一锤定音”：谷歌胜，甲骨文败。
最高法院的判决中包含两项关键的决议：
• 最高法院维持下级法院的原判，并裁定 API 受版权保护。
• Google 从 Java 复制 11,500 行代码的行为属于“合理使用”。
在此次案件诉讼期间，多位计算机科学家表示他们反对 API 受版权保护，同时他们也支持根据当前法律规定 Google 享有合理的使用权。
全球几乎每个企业组织和行业都离不开 API。API 是连接到互联网的每台计算机、网站、移动以及其他设备应用程序的管道。由于其普遍性，所以最高法院的判决将影响到所有人。

关于 Oracle 起诉 Google 侵犯版权案的背景介绍

2010 年，Oracle 在收购 Sun Microsystems 仅七个月之后，就通过加利福尼亚北区地方法院起诉 Google 侵犯版权和专利权。这一场旷日持久的斗争刚开始是两个单独的案件：一个是专利侵权案件，另一个是 2012 年与 Java API 有关的版权案件。最终，这两个案件合并成了一个案件，地方法院判定 Google 侵犯了版权，但没有侵犯专利权，而且法院的最终裁决声明 API 不享有版权保护。
Oracle 对此提出了上诉，并成功地推翻了先前的裁决。这一结果导致 Google 于 2019 年向最高法院提交了请愿书，并于 2020 年初举行了开庭审理。但是受疫情影响，该案件一直推迟到最近最高法院才做出了判决。
在 2020 年的法庭辩论中，最高法院根据《版权法》“合理使用”条款中规定的四个指导因素，对 Google 和 Oracle 的案件进行了审查：
• 使用的目的和性质；
• 受版权保护的作品的性质；
• 整体涉及版权的数量和实质性；
• 使用对受版权保护作品的潜在市场价值的影响。
最终，最高法院认为 Google 的行为属于“合理使用”。他们认为，首先 Google 并未复制所有的 Java API；其次，Google 复制的代码刚好满足他们对移动操作系统的需求，同时还确保了现有Java 开发人员足够熟悉他们的API，知道如何使用这些 API（这些都是支持 Google“合理使用”的关键论点）。
作为本案的一部分，下面我们就如何获得 API 版权的问题，分享一下我们的看法。

API 不应该有版权

API 非常抽象，甚至是开发人员也很难看明白，这就是为什么我们的行业经常采用各种类比来向他人解释什么是 API，什么不是 API。餐馆的菜单是我们最喜欢的类比之一，这个类比可以帮助我们理解 API 之间的关联性，以及为什么 API 不应该受版权保护。
API 就像餐馆的菜单一样，它们为饭店的数字资源提供了“结构、顺序和组织方式”。想象一下，即便是同样提供汉堡、薯条和奶昔的两个餐馆 A 和 B，也不能使用同一个菜单，两个菜单上的菜名、顺序和组织方式都不能完全相同。
菜单不受版权保护，API 也一样，餐馆提供的菜品与烹饪过程都有可能截然不同。菜单上汉堡、薯条和奶昔的结构、顺序和组织方式并不能创造出新颖的想法，最终还是要靠餐馆的菜品、烹饪过程和服务取胜。对于两家汉堡餐馆来说，菜单都是同一个概念，而且消费者对于汉堡、薯条和奶昔的理解也相同。但最终两家餐馆提供的菜单却完全不同。
同样，API 也不是知识产权。它们是操作的一部分，很常见、可重复使用、可重新结合，而且还可以供开发人员在各种应用程序中使用。
如果 API 拥有版权，则所有 API 开发人员都必须考虑为工作流程中每个重新实现或重用的 API 获取许可。如果开发人员设计的工作流需要 5～10 个不同的 API，那么他们就可能需要浏览 5～10 个许可。
为了探讨版权带来的不便之处，我们拿 AWS S3 API 来举个例子。对于每个API调用，开发人员都需要浏览API并获取API的“结构、顺序和组织方式”，以确定没有侵权。这就是为什么，如今有近 40 万国内开发人员都在使用 Eolinker ，因为他们可以通过 Eolinker 向 API 发出请求，并将（受版权保护的）API 的“结构、顺序和组织方式”保存到本地。 Eolinker可以帮助他们轻松地模拟API，并设计新的API，并通过协作与迭代表达自己的想法，然后根据需要或期望逐步进行修改。
备注：Eolinker是国内市场份额最大的API生命周期管理工具之一，支持免费使用和在线使用，详细可参考www.eolinker.com。

这就是2021年业务发展的方式，而且这种方式也满足了经济的持续增长。对桌面、Web、移动和设备应用程序的接口进行授权是上个世纪的商业模式。如今，很多行业的领导者都意识到，他们必须减少操作接口层的阻力，从而鼓励消费者（甚至是竞争对手）在其API之上构建应用。这是未来数字世界业务的发展趋势。

没有版权阻碍的 API 经济

尽管API享有版权保护已经很多年了，但API提供者和服务提供者并没有真正为API授权。再拿AWS S3 API举个例子，这一次我们来看一个真实的业务案例，存储提供商 Min.io 重用了 S3 API，他们在 AWS S3 存储 API 的基础上添加扩展、冗余以及其他功能。Min.io 自己的 API 使用的“结构、顺序和组织方式”与 AWS S3 API 完全相同。虽然 Min.io 很容易被视为 AWS S3 的竞争对手，但他们也为 AWS S3 的用户提供了附加价值，同时也为 AWS 创造了收入。
这种模式在经济发展的许多不同领域中反复出现，人们通过使用、重用和重新组合 API 来生成新类型的应用程序、集成，乃至全新的公司以及产品或服务。这类可公开使用的 API 资源和功能可以推动经济的发展，而且这种经济发展的速度非常快，瞬息万变，而且本身的构建目的是为了机器使用，因此根本来不及授权。我们互相协作，通过开放自由的 API 产生的价值远大于通过传统方法针对接口进行授权。
在 Google 与 Oracle 的案件中，最高法院对于“合理使用”的判决，很大程度上依赖于 Java API 的声明代码与实现代码之间的分离，因为开发人员看不到实现代码，而根据声明代码进行设计属于对 API 的“合理使用”。Java 之类的编程语言 API 与 Web API 之间的差别就更大了，而且随着这些 API 从使用语言框架进行部署发展到商品化的 API 网关（每个云平台和现代企业中普遍存在的通用 API 网关），这种差别会进一步加剧。
这也是很多开发人员都愿意接受最高法院关于“合理使用”定义的原因之一：API 与后端代码与系统的进一步分离，以及 API 规范格式（如 OpenAPI 和AsyncAPI）的使用，为我们提供了一个人类和机器都能够阅读的合约，我们需要量化 API 的“合理使用”范围，这种量化可以方便我们判断差异化，或者具体来说，方便我们比较两个 API 的范围、差异，以及是否存在重用。新的“合理使用”定义将帮助整个开发人员社区积极探讨我们共同设计、操作、交流、迭代、协作和重用 API 的方式，并为当前和未来经济的发展提供动力。

API 版权的下一步是什么？

Google 与 Oracle API 案件的讨论核心是语言库（Java API），但是，相应的 API 版权问题也会出现在 Web API，如今我们依赖的桌面、Web，移动和设备应用程序都离不开这些 API。我们建议每个人的 API 都采用尽可能宽泛的授权。
尽管 API 受版权保护，但大多数 API 提供商都明白减少 API 使用阻力的重要性，并且看到了使用现代 API 管理、速率限制和服务组合带来的 API 网关层的商机。下一代数字产品和服务的设计不会通过 API 的许可和限制来获取收益，相反，它们将竞相获取最新的数字资源和功能。
即使有些公司采取更为严格的 API 版权，但我们相信，他们也会从次版权诉讼的最终结果中吸取教训。在 Google 与 Oracle API 的这场旷日持久的斗争中，最高法院的判决消除了该行业的许多不确定性。该判决也符合日趋成熟的 API 格局、机器可读的 API 规范的增加，以及风险投资的更新。所有这些都为 API 行业的美好前景奠定了基础，实现了技术、商业和政治上的统一，这将有助于我们维持和迭代我们的旧技术基础架构，同时还可确保我们快速地发展人工智能、网络安全和科技行业的其他创新技术。

原文链接：https://blog.postman.com/google-vs-oracle-supreme-court-api-copyright-decision/