闹上美国最高法院后，硅谷史上最大的一桩恩怨终于了结了

@木遥：写一下我对美国最高法院今天对 Google vs. Oracle 案子的终审判决的理解（我没有法律专业背景，这是从工程师的角度写的）。

这案子缠讼十年，标的 88 亿美元，历经三次判决反转。其起因非常简单：Java 是一种在程序员中有非常高人气的语言，掌握在 Oracle 手里。Google 在推出安卓系统的时候为了能让更多给安卓写第三方 APP 的程序员尽快上手，直接在安卓 APP 开发工具里复用了大量 Java 的函数接口（API），但自己重新实现了函数本身。Oracle 据此告 Google 侵权。

这里的问题的核心是：一个语言的接口是否受到版权保护？对它的复用是否侵权？

Oracle 的论点非常直接（而且对非业内人士来说其实很有说服力）：软件是否受到版权保护？当然。接口是不是软件的重要组成部分？当然。那么接口显然应该受到版权保护。

Google 的论点就有点复杂，它需要详细辨析接口的含义 —— 对大多数法律界人士和公众来说，API 这个词本身就很陌生。最高法院判决的主笔是 82 岁的 Breyer 法官，他这辈子很可能一行代码都没写过。但从判决看，他是精确理解 API 的功能和内涵的。

被判决采纳的论点是：API 是一个发送指令的界面，像是汽车的加油踏板（这个例子在第一巡回法院之前关于 Lotus vs. Bortland 的判例里出现过），或者电脑的 QWERTY 键盘。—— 这两个例子不是随便举的，因为它们都正好反映出这个案子的实质：Google 是利用了现成的 Java 接口以吸引程序员能够迅速上手。这种「利用前人现成的知识节省学习成本」是应该受到保护还是惩罚？加油踏板就是这样一个类似的情况。第一个设计汽车的人已经把加油踏板设计成这样了，如果这种设计本身受到版权保护，每个后来的新的造车厂就都会面临一种两难，它要么继承这种设计但需要支付高昂的版权费用，要么另起炉灶但不会有用户买它的车，因为没人愿意买辆新车还要形成一套新的肌肉记忆。在 API 的情况里，判决指出：它的价值很大程度上体现为程序员群体对这种 API 的熟练掌握，以及复用这个 API 所能导致的学习成本节省。

因此这个判决的核心就是宣布：这种搭便车的做法属于合理应用（fair use），不应该被惩罚。其中最核心的（也是大部分评论最关注的）是这样一段论述：

「我们必须考量的是：对版权的保护是否促进了公众利益，是否促进了创新。」（第 31 页）

「考虑到程序员在学习 Java API 上的投资，如果把这个接口本身保护起来，会有害公众利益，因为这会迫使程序员不得不付出额外的努力去适应新的接口。新的创造就会被锁起来，而钥匙掌握在 Oracle 一家手里。这能让 Oracle 获得不菲的利润，但这些利润本来可以流向大量掌握了这些接口的人能创造出的新的应用之中。因此这种锁定是和版权的本意相违背的。」（第 34 页）

可以想像，这些论述（特别是关于公众利益的部分）的影响会非常深远。

以上是关于这个判决本身。但我还有一些其他的感想。

在这个具体的例子里，判决是和业界的 common sense 站在一起的。拷贝 Java 的接口（只占 Java 总代码量的极小比例）和拷贝 Java 的具体功能实现是两码事，不可同日而语。

但这里没有触及的问题是，对一个系统而言，设计接口并不是一项无足轻重的工作。在某种意义上来说，一个平台的接口和它背后的实现同样重要。接口有点像程序员世界里的「用户界面」，一个好的接口可以决定性地让一个平台取得优势。在某些极端的情况下，一个平台的价值可以主要就体现在接口上。比如机器学习最流行的平台之一 Keras，你可以说它整个就是一个 API —— 它把具体实现全都交给后台的 Tensorflow 或者 Theanos 来做了。（后来 Keras 被整合进了 Tensorflow，这里说的是最初版本的情形。）

法律依赖于比喻，而比喻永远是不精确的。如果把接口和实现的关系想像成一台巨大的机器外壳上的几个插头和内部丰富的实际功能组件，Google 的做法就相当于为了兼容性照搬外壳上几个插头的设计而内部完全自己另起炉灶。但现代软件工程并不是简单的机器，你很难清晰拆分出外壳和内部。大多数情况下，你看到的是一层层功能的封装，大量的智慧都投入在巧妙的封装本身上，而最底层的实现很可能只是继承经典而已。问题在于，你如何能把现代软件工程比喻成一个现实生活中的例子呢？

区块链是一个极端的情形。2016 年，联合广场投资的分析师 Joel Monegro 写了一篇极为著名的文章： fat-protocols。他指出，和传统网络领域里协议很轻而应用很重的情形相反，在区块链的世界里，协议是「胖的」，而应用无足轻重。投资于应用远不如投资协议回报丰厚。例如以太坊是一个伟大的协议，它的价值远远胜过在运行在以太坊上的具体应用本身。—— 协议（protocol）当然和接口（API）不完全是同一个概念，但它们是强烈相关联的。复制以太坊的全部接口差不多就相当于复制了以太坊本身。这件事又应该如何被比喻到现实世界之中呢？

当然，这并不意味着今天的判决表示你可以直接复制一整个 Keras 或者以太坊。在 Google 的案例里还有许多别的因素需要考量（其中很重要的一点是 transformative use，也就是说，Google 并不是打算创造一个 Java 的等价竞品出来，安卓和 Java 是两个不同领域的东西）。但这个判决毕竟在比喻的边界处划了一条明确的界限。—— 从今天业界的反应来看，这个界限得到了几乎一面倒（除了 Oracle 以外）的业内支持。

但其长远影响有待分晓。