Google 诉 Oracle 案对开源的意义

Google 诉 Oracle 案最终以美国最高法院 6 比 2 的压倒性裁决 告终，该裁决支持 Google，并进一步明确了应用程序编程接口 (API) 使用的自由度。软件开发人员可以从这项裁决中受益。

由于 Google 和 Oracle 之间的诉讼可能对 API 的重用产生影响，开源社区一直密切关注此案。几十年来，人们一直认为 API 不受版权保护，任何人都可以自由使用 API 来创建新的和改进的软件模块，以及与使用此类接口的现有模块集成。

此案涉及 Google 在创建 Android 时使用了 Oracle Java SE 中 API 的一部分。此案在下级法院经历了 10 多年的漫长诉讼。美国联邦巡回上诉法院 (CAFC) 此前裁定：1) Oracle 对 Google 复制的 Java SE API 部分的版权是可受版权保护的；2) 根据法律，Google 的使用不属于合理使用。这意味着 Google 将因在 Android 中使用的 Oracle Java SE API 部分而承担版权侵权责任。如果这项裁决维持不变，不仅对 Google 来说是一个损失，对包括开源在内的软件开发社区来说也是一个损失。

几十年来，不受限制地使用 API 一直是常态，也是创新的关键驱动力，包括现代互联网以及无数使用此类接口相互通信的软件模块和设备。事实上，在 Oracle 决定就此提起联邦诉讼之前，软件行业很少关注 API 的使用。

软件行业为此经历了十多年的动荡，这令人遗憾。然而，最高法院的裁决为分析软件接口的使用提供了新的解释和框架，这在很大程度上是好消息。简而言之，虽然法院没有推翻版权适格性裁决（从软件开发人员的角度来看，这将是最好的消息），但它在 Google 的使用是否在法律上属于合理使用的问题上，强烈支持 Google。

什么是 API？这取决于你问谁

在更详细地描述此案及其结果对软件开发人员的意义之前，我需要定义 API。这是一个重要的困惑来源，而且法院采纳的定义与传统含义不符，这让情况变得更糟。

最高法院使用下图来描述它所指的 API

图片来源：

^{（来源：Google LLC 诉 Oracle America, Inc., No. 18-956, US 2021 年 4 月 5 日；第 38 页）}

在法院的定义中，API 包括“声明代码”和“实现代码”——这是法院采用的术语，尽管 Java 或其他编程语言的开发人员不使用这些术语。声明代码（Java 开发人员称之为方法声明）声明了方法的名称及其输入和输出。在上面的示例中，声明代码声明了方法名称“max”，并进一步声明它接收两个整数“x”和“y”，并返回一个整数结果。

实现代码（Java 开发人员称之为方法体）由实现方法功能的指令组成。因此，在上面的示例中，实现代码将使用计算机指令和逻辑来确定 x 或 y 是否是较大的数字，并返回较大的数字。

此案争议的焦点仅在于声明代码。Google 被指控抄袭了 Java SE 的部分声明代码，用于 Android 以及该声明代码的“结构、顺序和组织”。在本案的最后阶段，Google 没有被指控抄袭任何实现代码。案件当事方承认，Google 为 Android 编写了自己的实现代码。

声明代码是大多数人所指的 API；而不是法院对 API 的定义，法院的定义将声明代码和实现代码结合在一起。声明代码本质上是一个“软件接口”，允许访问软件模块的各种方法。换句话说，它允许一个软件模块与另一个软件模块交互、传递信息以及控制另一个软件模块。

我将把声明代码称为“软件接口”，因为这是本案中行业关注的问题。根据此定义，软件接口不包括任何实现代码。

现在，言归正传……。

以下是更详细的解释，说明最高法院的案件具体意味着什么。

Google 被指控抄袭了 Java SE 的某些声明代码，用于 Android。它不仅抄袭了许多方法的名称，而且在这样做时，还抄袭了该声明代码的结构、顺序和组织（例如，代码如何组织成包、类等）。根据美国版权法，结构、顺序和组织 (SSO) 可能受到保护。此案在法院之间来回审理多年，其历史对于法学学者来说引人入胜。但是，就我们的目的而言，我将直奔主题。

如果作品不受版权保护，那么通常可以不受限制地使用它。Google 强烈辩称，它复制的声明代码正是如此——不受版权保护。支持其不可版权性的论点包括，它是一种不受保护的方法或操作系统，美国版权法明确规定它不在保护范围之内。事实上，这是 Red Hat 和 IBM 在他们于 2020 年 1 月向最高法院提交的 “法庭之友”简报中提出的论点。如果法院裁定 Google 复制的声明代码不受版权保护，那么这将是故事的结局，也是对开发人员社区来说绝对最好的情况。

遗憾的是，我们没有从法院获得这一点，但我们获得了次好的结果。

作为我对刚才所说内容的推论，未经版权所有者的许可，复制或修改他人的受版权保护的作品（例如书籍、图片甚至软件）可能会使您陷入法律风险。这是因为受版权保护作品的所有者拥有复制和进行更改（也称为衍生作品）的专有权利。因此，除非您拥有许可（可能是开源许可或专有许可）或合理使用抗辩，否则您不能复制或更改他人的受版权保护的作品。合理使用是对使用他人受版权保护作品的一种抗辩，我将在稍后讨论。

好消息是，最高法院没有裁定 Oracle 的声明代码具有版权。它明确选择回避这个问题，并在更狭隘的基础上裁决此案。但它似乎也表示支持这样一种立场，即声明代码即使可以获得版权，也比法院认为的版权核心更远。¹ 未来的下级法院有可能裁定软件接口不受版权保护。（有关此问题的更全面描述，请参见本文末尾。）这是个好消息。

最高法院实际上做的是，为了论证起见，假设 Oracle 对声明代码（即软件接口）拥有有效的版权，并在此基础上，它询问 Google 的使用是否属于合理使用抗辩。结果是响亮的“是”！

何时合理使用才算合理？

最高法院的裁决认为，Google 对 Java SE 部分声明代码的使用属于合理使用。合理使用是对版权侵权的一种抗辩，如果您在技术上侵犯了他人的版权，那么根据合理使用，您的使用可能会被原谅。学术界是合理使用可以在许多情况下提供有力抗辩的一个例子（仅举几例）。

法院由此开始分析合理使用的每个因素，以查看它是否以及如何适用于 Google 的情况。由于身处学术界之外（在学术界，此类问题相对容易确定），这种情况需要更仔细地分析法律规定的合理使用因素。

合理使用是一项因素测试。美国版权法中描述了四个因素，用于确定合理使用是否适用（尽管法院也可以考虑其他因素）。有关合理使用的更全面描述，请参阅美国版权局的这篇文章。合理使用的棘手之处在于，并非所有因素都需要存在，并且一个因素的权重可能不如另一个因素。根据案件中的事实，某些因素甚至可能相互关联，相互拉扯。最高法院裁决的幸运结果是，它在所有四个法定因素上都做出了有利于 Google 的裁决，并且是以 6 比 2 的结果做出的。情况远非处于边缘；远非如此。

对软件开发人员的影响

下面，我将提供我对软件开发人员或律师在评估软件接口的重用是否属于法律规定的合理使用时应考虑因素的看法。这种看法基于最高法院最近的裁决。以下内容应作为指导，帮助您为法院提供更多机会，以便在以下不太可能发生的情况下将您的使用视为合理使用：1) 您对软件接口的使用受到质疑；2) 该软件接口被认定为可受版权保护的……但这种情况可能永远不会发生，因为最高法院并未裁定它们可受版权保护。相反，它将这个问题留给下级法院来裁决。

在深入探讨这一点之前，有必要简要讨论一下用例。

软件接口使用主要有两种用例。在 Google 案中，它是为 Android 重新实现 Java SE 软件接口的部分内容。这意味着它保留了相同的声明代码，并为每个方法声明重写了所有适用的实现代码。我将此称为“重新实现”，它类似于最高法院裁决中使用的上图的右侧。这在开源社区中非常常见：一个模块具有许多其他软件系统和模块可以使用的软件接口，而富有创造力的开发人员通过以新的实现代码形式创建新的和改进的实现来改进该模块。通过为每个改进的方法使用相同的声明代码，预先存在的软件系统和模块可以使用改进的模块，而无需重写任何代码，或者可能只需进行最少的重写。这是一个巨大的好处，并为开源开发生态系统提供了强大的动力。

第二种常见的用例（如下图的左侧所示）使用软件接口来启用一个软件模块和另一个软件模块之间的通信和控制。这允许一个模块使用该软件接口调用另一个模块中的各种方法。尽管最高法院的裁决中未具体提及第二种用例，但我认为，在所有情况下（最不寻常的情况除外），这种使用可能在非版权适格性和合理使用抗辩方面具有更强的论据。

遵守合理使用的 4 个技巧

无论您只是使用软件接口来实现对另一个软件模块的控制和通信，还是使用您自己新的和改进的实现代码重新实现现有软件模块，以下准则都将根据最高法院的最新解释，帮助您将您的使用保持在合理使用范围内。

1. 对于上述两种用例，软件接口的使用量不得超过与另一个软件模块进行交互所需的量。此外，还要注意您复制的作品量。您复制的整体作品越少，这个合理使用因素就越有利于您。
2. 在重新实现和改进现有模块时，请编写自己的实现代码。
3. 避免使用任何其他模块的实现代码，除了可能在其他模块的实现代码中全部或部分复制的任何声明代码。这种情况有时会发生，而且通常是不可避免的。
4. 尽可能使您的实现具有变革性。这意味着添加一些新的东西，具有更进一步的目的或不同的特性。在 Google 的情况下，它转换了 Java SE 的部分内容，以便更好地在移动环境中使用。这被认为是本案中的一个因素。

API 可以受版权保护吗？

那么 API 的版权适格性以及最高法院未就此问题作出裁决的奇怪情况又如何呢？这是否意味着 API 实际上是可以获得版权的？否则，我们为什么要进行合理使用分析？绝妙的问题！

答案可能是，但在我看来，在大多数司法管辖区不太可能。在一个奇怪的怪癖中，本案是从最初的审判法院上诉到 CAFC，而不是上诉到第九美国巡回上诉法院，后者本应是在旧金山审判法院审理的案件的传统上诉途径。CAFC 通常不审理像 Oracle 诉 Google 这样的版权案件。² 虽然 CAFC 在裁决此案时适用了第九巡回法院的法律，但第九巡回法院不应受该裁决的约束。

美国有 13 个联邦上诉法院。因此，虽然 CAFC（但不是美国最高法院）裁定软件接口受版权保护，但其裁决对其他上诉法院，甚至对 CAFC 均不具有约束力，除非在 CAFC 适用第九巡回法院法律的罕见情况下。但是，该裁决可能在其他审查第九巡回法院版权适格性的案件中具有“说服力”。在我们的上诉法院系统中，CAFC 关于版权适格性的裁决具有约束力的案件和情况只占很小一部分。

但是，即使 CAFC 根据第九巡回法院（或另一个巡回法院）的法律审理关于软件接口的案件，并裁定某个软件接口在该法律下受版权保护，我们仍然有最高法院的这项非常广泛且有力的裁决，该裁决为合理使用原则作为对此类使用的可行抗辩提供了明确的框架和有力的信息。

您对他人软件接口的使用会受到质疑吗？正如我所说，在发生此案之前，软件接口的重用已经进行了几十年，但鲜为人知。

1. “我们认为，……声明代码即使可以获得版权，也比大多数计算机程序（例如实现代码）更远离版权的核心。” Google LLC 诉 Oracle America, Inc., No. 18-956, (US, 2021 年 4 月 5 日)

2. CAFC 审理此案仅仅是因为它最初与一项专利索赔有关，而该专利索赔最终从案件中撤销。如果不是因为专利索赔，此案本应由第九巡回上诉法院审理。