甲骨文公司与 Google 之间的官司已经进入尾声，而它将会对编程的未来起到一个决定性的作用。两家公司的律师将会提交他们在这场官司中的结案陈词，对于 Google 是否违规使用了 Java API 这个 Android 系统至关重要的组成部分，这会是他们最终的较量。但不管陪审团如何判决，这个案件已经对软件开发这个领域造成了永久性的影响。
作为一个对科技行业拥有如此大的潜在影响力的案件，想要追根溯源可没那么容易。这个案件前前后后拖了好几年，在技术和法律上的细节之处都有许多值得深思的地方。但是，对那些关心商业和技术未来的人们来说，你必须要理解它。因此，我们将尽力让你能理解它所将要产生的意义是什么。
甲骨文公司在 2010 年 1 月的时候收购了 Java 语言的开发者 Sun，然后在那年 8 月的时候，甲骨文公司向法院起诉 Google 在 Android 系统中的 Java 相关技术上侵犯了甲骨文公司的版权和专利；除此之外，甲骨文还声称 Google 在 Android 系统中对 Java API 的使用侵犯了它的版权。在 2012 年的时候，华盛顿特区的地区法院判决 Google 胜诉，他们发现这些 API 不受版权的保护。但对 Google 来说，不幸的是上诉法院推翻了这一判决，而美国最高法院又拒绝审理此案。
所以现在，甲骨文和 Google 又回到了地区法院，它将会决定 Google 对这些 API 的使用是否是合法的。如果成立，这意味着 Google 不必从版权拥有者那里获得许可就能使用它们。而这个结果将会对整个软件行业造成巨大的影响。
赌注是什么？
首先，这个官司是不会杀死 Android 系统的，Google 已经承诺，在未来的操作系统中他们只会使用 Java 语言的一个完全开源版本。但是，由于上诉法院已经裁定 API 受版权法的保护，这可能会为初创企业和开源项目们展示出一个全新的法律界限：因为这些企业和项目经常要使用那些 API 以确保他们的产品能追上当前的潮流。
举个例子，有许多公司都开发了能兼容多个云服务的开源软件，此举能让客户轻松地将他们的应用从亚马逊这类云服务商中转移到他们自己的数据中心。比如 Basho 和 SwiftStack，这两家公司都能提供与亚马逊 S3 服务相媲美的存储类产品，但由于 API 受到版权法的保护，亚马逊在理论上就能控诉这两家公司侵权。
同时，许多像 FreeBSD 这样基于 Linux 系统的开源操作系统都使用的是名为 POSIX 的标准化 API，而它又是基于一种更古老的 Unix 操作系统的 API。如果我们根据上诉法院的判决，Micro Focus——这个 Unix 的所有者——就能起诉 POSIX 操作系统的制造商们。
「无论陪审团如何裁定，上面这两种情况都与甲骨文和 Google 之间的争议有异曲同工之处」，说话的人是 Mitch Stoltz，他是一名电子前沿基金会（Electronic Frontier Foundation）的高级律师。
从这个意义上讲，这个案件已经对软件行业造成了一个严重的打击，因为不管你是否违法，对侵权诉讼的辩解都会是一个漫长而又花费不菲的过程。这种对于法律纠纷的恐惧很可能使得那些想要使用受版权保护 API 去开发新软件的开发者们望而却步。如果法庭能在判决上考虑一下 Google 的合理使用问题，那企业也许能有更多的希望去赢得这样的法律纠纷。但另一方面，如果法庭站在甲骨文的立场上，那对 API 的再使用就要指望版权所有者的态度了。
想要解释什么是 API 仍然不是一件容易的事
在这件案子中，对于 Google 来说，有一个很关键的问题就是：他们如何向法官和陪审团解释到底什么是 API（Application Programming Interface）。负责这个案件的法官 William Alsup 为了更好地理解这件事的来龙去脉还去自学了 Java 编程。
在他 2012 年的裁决中，他将 API 描述为一种有点像图书馆的东西。
「每一个 package 就像是图书馆中的一个书架」，Alsup 在他 2012 年的裁决中说道，「每一个 class 就像是书架上的每一本书，而每一个 method 就像是书中的一个指导章节。走到正确的书架前，选择合适的那一本书，然后打开它，翻到正确的章节处，那就是你想要的东西。」
通过在实质上像 Java 语言的组织方式一样组织他们自己的软件库，Google 让 Java 程序员们在 Android 系统上能更轻松地编写软件。现在的问题是，虽然甲骨文提供了一个开源的 Java 版本，这意味着每个人都能自由地修改、调整和共享底层代码；但 Sun 公司本身的许可条款禁止其他公司在没有他们允许的情况下建立自己的语言版本。不过 Alsup 裁定 Google 的 Android 平台不是一个真正的 Java 实现（a Java implemention），他们只是借用了那个 API。
尽管上诉法院最终否决了 Alsup 的结论，但实话讲，虽然忽略了一些技术上的问题，但 Alsup 的说法仍然是一个好的比喻。
但是，Google 更喜欢用「文件柜」来比喻这个事件。
这家公司的律师在 2012 年的时候用一个真实世界中的文件柜来解释这一切，他们认为 API 只是每个文件上的标签，而每个文件里面的内容才是真正应该受到版权保护的东西。但这个解释并没有被接受。
「当你发现坐在你前面的那个人在法庭质询的时候还在 StubHub（美国的在线票务网站）上买票，你就会知道大家对这件事的理解程度有多少了」，这是 The Verge 当时在法院作出的报道。
不过，这仍然无法解释为什么 Google 律师在当时没有选择 Alsup 法官更具说服力的说法而用了自己那个「文件柜」的比喻。外媒 Motherboard 的科技编辑 Sarah Jeong（非常了解 API 的一位专业人士）就表示她无法理解这位律师的解释，而这对于 Google 来说可不是一个好的现象。
甲骨文出示了一些让 Google 看起来很不利的邮件
甲骨文公司的律师则发现了两封对 Google 很不利的邮件，这两封邮件都是建议 Google 好好了解一下这些受版权保护的 API 的。根据报道，其中一封是 Android 系统的创始人 Andy Rubin 写的，他写道：「祝他们好运，Java.lang.apis 是受版权保护的。」而另一封则由 Sun 公司发出，其中他们也写到「要决定一下究竟谁才有使用这些 API 的许可权」。
在一封发给 Rubin 的邮件中，工程师 Tim Lindholm 写道：「在我们看来，我们需要根据我们自己的需求协商出一个 Java 的许可证。」
这些邮件并不必然证明 Google 错了，因为它们不是由 Google 的律师发出的，而它们也无法证明这些 API 的使用不合法。但它们看起来肯定对 Google 不利。
来自 Sun 的支持
也不是所有的事情都对 Google 不利。Sun 公司的前任 CEO Jonathan Schwartz 告诉法庭说 Sun 一直是一家自由且开放的公司，他们一直觉得 Google 对这些 API 的使用没问题。
而 Schwartz 的证词与他在 Android 系统推出时发布的公开声明是一致的。「我衷心的祝贺 Google 宣布了他们新的 Java/Linux 手机平台——Android。」这是他在 2007 年写在 Sun 官网上的话。
而甲骨文公司的律师 Peter Bick 则想办法推翻 Schwartz 的说法，他通过阅读 Schwartz 在当时发送的邮件寻找一些漏洞，比如 Schwartz 可能对 Android 系统使用了「不完整」这类的词语。Bick 还设法对 Schwartz 的领导权发出一些质疑，比如他就指出甲骨文在收购了 Sun 之后并没有给他一个很高的职位。Bick 还指出 Schwartz 一度被称为当时最糟糕的 CEO 之一。换句话说，Bick 在试图将 Schwartz 的决定描绘成是「一位糟糕的 CEO 所做的一个违法的决定」。
未来可能出现的场景
尽管目前甲骨文公司更受陪审团的青睐一些，但我们并没有丧失一切软件开发的未来。许多更新一代的开发平台，比如 Google 的 Go 语言和苹果的 Swift，都拥有比 Java 更宽松的许可条件，他们都允许盈利性的公司使用并修改他们。
同时，微软也在开源他们推出已久的.NET 编程平台；同时，也有两家创业公司同思科、IBM 和 Intel 一起在开发一个全新的开源技术标准。这些也许能帮助我们在未来减少这样的法律纠纷。
如果你觉得因为甲骨文公司可能的胜利就会引发一大批关于 API 的法律纠纷，那你就错了。很多的此类事件并不一定会显现出来。亚马逊公司就没有回复我们有关他们的 AWS 服务 API 的相关使用许可问题；但 Gartner 的分析师 Raj Bala 告诉我们说，阻止其他人使用 AWS 的 API 并不符合亚马逊的最大利益。「AWS 控制着每一家使用了其 S3 API 的存储供应商的路线图部分，其中包括了 IBM、Google 和 EMC 等等」，他说道，「为什么亚马逊要打乱自己的这股强大能量呢？对于一家公司来说，将自己的私有协议变成行业标准，还有比这更有利的事吗？」而 Google 这个亚马逊在云服务方面最大的竞争对手之一也已经开源了其关键的云技术，比如 Kubernetes。
这些越来越多的开源技术能给开发者们更多的信心，他们能用这些开放性的技术去开发自己的软件而不必担心有法律问题。无论陪审团将会做出何种决定，拥抱这种开放性的企业一定会统治未来。
文章转载自 开源中国社区[http://www.oschina.net]