图片来源@视觉中国

钛媒体注：本文来自于微信公众号硅星人（ID：guixingren123），文丨杜晨，编辑丨Vicky Xiao，钛媒体经授权发布。

没有永远的敌人，只有永恒的利益。

而为了争夺 Android 操作系统内37个API，共约1.15万行代码的著作权，以及这些代码所代表和引申的大半个移动计算市场的，巨大的已知和潜在的经济利益——甲骨文和谷歌，硅谷久负盛名的两家软件技术公司，已经打了十年的官司。

而在4月5日周一，这场旷日持久的斗争，终于画了一个在绝大多数科技从业者看来都较为圆满的句号：

美国最高法院认为谷歌在 Android 当中合理使用 (fair use) 甲骨文的 Java API，以6-2的比数结果，判决谷歌胜诉。

“计算机程序是功能性的，这一事实令人难以在科技的世界中沿用传统的著作权观念。按照本庭的判例和法律中的合理使用规范，本庭认为，谷歌拷贝（甲骨文 Java）API 用于重新开发一种用户界面，且只提取那些对于（开发者）用户施展才能开发全新和变革性程序而有用的部分，是一种合法合理使用的行为。本宣判不作为对本庭其它合法使用案件判决的推翻。”

——美国最高法院大法官史蒂芬·布雷耶在判决书中写道。

这一最新判决，不仅帮助谷歌避免了一笔高达88亿美元的赔偿金，还重新确立了该公司当年大比例照抄甲骨文 Java API，这一行为的合法性和正义性。

谷歌全球事务高级副总裁 Kent Walker 表示，高院的判决是消费者的胜利，对于软件开发行业的互操作性，对于整个计算机科学领域都有帮助。“这一判决将赋予下一代开发者们更多的确定性，让他们的新产品和服务继续为消费者创造价值。”

很明显，甲骨文对于判决结果非常不满意，但毕竟已经上到高院，解决问题可走的法律途径已经到了尽头，也只能将矛盾转移到“垄断”上。

甲骨文法务总管 Dorian Daley 在声明中表示，“谷歌的平台越来越大，市场统治力越来越强；其他人参与竞争的门槛越来越高，竞争力越来越低。谷歌偷走了 Java 技术，并且在长达十年的时间里以一个垄断者的姿态诉诸法律。这样的行为恰巧也印证了为什么全球和美国监管机构都在调查谷歌的商业行为。”

美国高院此次也推翻了此前低级法庭于2014年下达的对甲骨文有利的判决。此前，美国联邦巡回上诉法庭判决认为，公司对于它们开发的 API 拥有著作权。

而这一前序判决对广大第三方开发者来说非常不友好，因为这可能意味着他们在开发软件的时候，为了避免被版权流氓找上门收费，可能不得不放弃使用现行的 API，从零开始自己开发。

因此，高院的最新判决对于这些第三方开发者，特别是并没有多少版权和法务预算的中小开发者来说，更是个天大的好消息。

斯坦福大学网络政策中心主任、前 Facebook 首席安全官 Alex Stamos 对此喜出望外："感谢高院这一判决，帮助整个科技领域避开了来自版权流氓的屠杀。"

谷歌元老、第8号员工 Urs Hölzle 也深表欣慰：“高院此举维持了上世纪80年代的判例，也即任何人都不能阻止其他人独立地使用 API 来开发兼容版本。”

在这场横跨十年，历经三级法院、两次上诉的漫长恩怨的背后，既有年轻科技公司对既得利益者的光荣挑战，也有确实不太体面的偷鸡摸狗和勾心斗角。谷歌和甲骨文都声称自己是正义的受害者，它们的主张也都有法律支持的合法性，但与此同时，科技行业赢家通吃的规则也都让他们不得不用尽一切办法维护自己的利益。

但总的来说，围绕 Android/Java API 的这场十年斗争，其实最后还是要从创新的角度，以及从普通消费者和中小开发者的视角来看：谁促成了创新，谁又试图将竞争对手扼杀在摇篮中；谁的主张能够代表更多人的利益，谁的主张仅仅是为了稳固自己的城池。

最终，答案显而易见：谷歌一方，在这起案件中占尽了优势；而甲骨文这边，过去以来一直背负着版权/专利流氓的负面形象，失道寡助，就连前任美国政府公开站队支持，也未能最终扳回命运。

当然，作为普通的科技从业者的我们，扮演更多的确实是吃瓜者的身份……而在甲骨文vs谷歌的十年斗争中，也确实发生了不少关键事件、重大反转，以及有趣的庭上交锋轶事。

今天，就让我们来一起回顾这场硅谷史诗级巨头恩怨的前因、中途，和后果。

大公司的事，怎么能叫抄呢

15年前，谷歌在搜索广告以及电子邮件基础办公软件等领域已经有了不错的业务水平，急于寻找新的增长点——移动计算。最终，公司高层决定开发一个移动操作系统，于2005年收购了 Android 公司。

一个全新的操作系统，并不意味着关于它的一切都是全新的。一个平台仅靠自己不能成功，还需要广大开发者的支持，也正因此，谷歌需要开发者能够尽快上手为未来的 Android 开发程序。当时的重中之重，是确定一个开发语言。

围绕这个关键任务，创始人拉里·佩奇、谢尔盖·布林、当时的谷歌“监护人”埃里克·施密特，以及“安卓之父”安迪·鲁宾，以及相关项目的关键人员展开了讨论。最终大家认为，由当时的 Sun Microsystems 开发的 Java 语言是最适合的选项。

一份谷歌当时的会议内部文件写道，Android 项目想要采用 Java “必须从 Sun 获取授权”，“（授权）成本并不是问题，开源 JVM（Java 虚拟机）才是。”

出于合规操作的想法，谷歌派遣工程师 Tim Lindholm 开始了和 Sun 的谈判，寻求 Sun 授权谷歌使用 OSS J2ME JVM。

按照这位工程师后来的解释，当时谷歌真的已经穷尽了所有的 Java 替代方案，“我们认为他们都很逊。我们认为需要按照我们的需要谈下一个 Java 授权。”

但是谈判并不算顺利，Android 项目的推进困难重重。按照鲁宾在2005年给佩奇的一封邮件，当时的谷歌只有两个选择：1）放弃 Java 方向，转投微软的 CLR 虚拟机技术并采用 C# 语言；2）不管 Sun，维持采用 Java 的决定，“可能在过程中（与 Sun）树敌。”

谷歌做出了决定，直接大段复制了 Sun 的 Java API 原始代码，做了些许微调，并最终于2008年发布。

2007年鲁宾在给施密特的一封邮件里承认了自己确实没有别的选择：“我不知道我们还能怎样（和 Sun）合作，并且避免关于（对于 Java API 相关代码）控制权的争斗。我跟 Sun 已经没什么好说了。等到我们发布的那天他们一定不会开心的，但至少我们现在能够和整个行业并行，而这一切只是开始。”

以上内容均来自甲骨文后来首次起诉谷歌时调查取证得到的往来邮件记录，其中还有一些邮件，曾经被谷歌千方设法不被法庭采用，但最终还是没能避免公之于众。

可以说，谷歌当时做这些事情的时候仍然是有罪恶感的。在发布 Android 的大会上，谷歌工程师不可避免要演示技术、回答感兴趣的开发者抛出的问题，鲁宾当时告知团队，所有的演示和问题解答必须一对一，不能在任何 Sun 员工或律师的面前进行演示。

而在甲骨文看来，谷歌的这些行为是赤裸的侵犯著作权行为。它最有力的证据，除了前述的这些谷歌内部往来邮件之外，还有 Sun 在2004年成功申请到的 Java 的著作权证书：

根据时任甲骨文 CFO Safra Catz（现任 CEO）的证词，因为甲骨文的产品和服务大量基于 Java，她担心 Sun 在未来被其它公司收购导致甲骨文失去对 Java 的控制权，从而公司业务风险提高，于是才下定决心收购 Sun。

但考虑到甲骨文2009年收购了 Sun 之后过了一年就正式对谷歌提起诉讼，指控其侵犯 Java 著作权，当时也有一种颇为主流的声音认为，Catz 口中的“其它公司”正是谷歌。当时还有业界传闻甲骨文还在考虑收购 RIM（黑莓公司）或者 Palm 从而进入智能手机行业（后来得到了创始人 Larry Ellison 证实），所以甲骨文起诉谷歌也是为了给未来争夺移动计算市场份额而铺路。（Catz 后来解释称，她当时担心的是 IBM。）

当时的谷歌，颜面也确实不太好看。

2012年，面对原告的举证和法官的质询，时任谷歌 CEO 的 Page 出庭作证表示自己“不认为我们做错了什么事情”，并且试图推卸责任，宣称不了解有没有从甲骨文逐字逐句逐标点符号抄袭了 Java API 的代码、自己没有参与此事件的决策当中，以及鲁宾和自己之间并没有正式的汇报关系……

老板都甩锅了，下属也确实有点难做。

在庭上，时任 Android 核心库开发负责人的 Bob Lee 表示写代码的时候确实有“参考”过 Sun 的开发手册，从而“确保软件互操作性。”

从 Sun 跳槽到谷歌担任 Android 项目首席架构师的 Joshua Bloch，在出庭作证时也表示：在（当时开发进度的）压力之下，他不记得自己从 Sun 抄袭过任何受到著作权保护的代码，但 Android 里的 Java 代码“确实是我写的，我丝毫不会反驳这一点。如果我确实做了（抄袭的事情），那可能是个错误，我表示歉意。”

虽然面子上过不去，谷歌的主张还是较为令人信服的：

Sun 开发的 Java 语言是可供公众使用的；

谷歌开发 Android 采用的是免费和开源的技术；

Sun 公开认可过 Android 对于 Java 的使用；

谷歌对 Java API 的使用是合理使用行为 (fair use)。

具体来说，谷歌指出，Ellison 自己在2011年的一份证词中表示过，没有人真正拥有 Java 编程语言，任何人都可以不付费使用它；以及，甲骨文自己的专家证人也曾经表示，这些 Java 的构成元素“就像言论的一部分”——而言论是不可被著作权保护的：

谷歌还引用了时任 Sun CEO Jonathan Schwartz 在2007年的一篇公开的博客文章。在这篇文章里，Schwartz 评价谷歌推出 Android “为开发者社区绑上了（增长的）火箭，并且将谷歌定性为”朋友“；在私下，Schwartz 也对 Android 赞叹有加，曾在写给施密特的邮件里表示过乐意支持 Android 的发布工作——所有的这些，鲁宾和施密特都当作 Sun 对谷歌当时行为的一种默许。

Schwartz 甚至在2012年直接出庭作证，为谷歌一方辩护。他对甲骨文的律师表示，自己一直在等待着甲骨文方面的传唤，但是没等到，“我以为甲骨文对于我领导公司的方式很不满……而如果谷歌传唤我的话，我想他们一定认为我可以带来一些价值。”

他在庭上表示，在自己看来，Sun 一直以来的意图，都是让 Java 语言和 API 免费供任何人使用。而 Sun 赚钱的方式，是从想用 Java 商标和 Java 兼容性来宣传自己的公司那里赚取授权费用。

根据施密特的估计，在授权谈判过程中，Sun 的要价大概在3000到5000万美元之间；鲁宾认为 Sun 最终愿意接受的价格在2800万美元左右。按照谷歌2005年大约520亿美元的市值，这笔小钱简直是九牛一毛（甚至后来这么多年跟甲骨文缠斗的法务开销可能都更多一些）。可为什么当时的谷歌就这么一毛不拔呢？

原来，鲁宾自认为已经看透，当时的 Sun 是一家进入黄昏时代的公司，员工没什么才能，技术（除了 Java 之外）无甚特长，对于 Android “带来不了增加价值。”

如果接受 Sun 的授权，意味着将来 Sun 在 Android 未来的发展当中都将拥有一票话语权——而这在鲁宾看来，无论对于 Android 的客观发展，还是谷歌主观上对 Java 社区的掌控欲来说，都不是件好事。

在写给施密特的邮件中，鲁宾甚至直接将 Sun 的存在比喻为排泄物，声称：“移动设备市场已经足够成熟，可以容许像谷歌这样的创新者来冲走那些浮在碗里太多年的 crap” (The handset industry is ripe for an innovator like Google to flush out the crap that's been circling the bowl for years.)

所以，这里谷歌的核心目标是：将 Sun/甲骨文描绘成一个曾经和自己朋朋友友、推杯换盏，进军移动计算市场失败之后又生气翻脸，企图敲诈行业领先者的版权/专利流氓，和扼杀技术/商业模式创新的既得利益者……

相信很多人都对这起诉讼有着类似的观感。

而且，就连甲骨文的 Catz 也在庭上表示，“想要跟免费竞争还是挺难的。”

难断的案，和拿不定主意的陪审团

从高维度上来看，甲骨文起诉谷歌 Java API 侵权一案，其实非常简单：抄了就是抄了；到了具体审理过程中，此案却又非常复杂，涵盖了著作权、专利权、合理使用等多个方面。

这可能也是一审法官 Willliam Alsup 和12位陪审团成员首次遭遇如此复杂的科技法律难题。

围绕此案“合理使用”部分的一审过程中，陪审团在长达一周的案情认定过程中无法达成一致，以至于 Alsup 法官不得不传召他们回到庭上，表示“各位辛苦了。”

一名陪审员甚至发问：如果陪审团一直无法达成一致，陷入僵局 (deadlock)，这案子到底该怎样进行下去？由于审理过程实在太漫长，一名陪审员出于对案情的迷惑，“不小心”违反了陪审团原则，私下和自己的丈夫讨论了可能和案情有关的事项——往往只在律政电视剧里才能看到的情况……

最终，在2012年5月7日，陪审团传达了他们的部分判决意见：认定谷歌确实侵犯了甲骨文持有的 Java 相关著作权。

得到了有利判决，甲骨文方面当庭请求启动追偿流程，要求谷歌将 Android 带来的一部分利润赔偿给甲骨文——这一请求旋即遭到法官驳回。此案有无数种还未探清的可能性，法官还不想这么早就许诺给甲骨文他们最想要的东西——钱。

关键在于，就“合理使用”一项，陪审团无法就“谷歌的行为是否构成对 Java 技术的合理使用”达成一致。

甲骨文方面请求法官 Alsup 就“合理使用”一项直接依法律判决，也即逾越陪审团未达成一致的事实，让法官来直接宣判。这一请求再次遭到拒绝，法官当庭表示，考虑到已经呈堂的证据，由他来下达判决并不公平。

法官甚至直接斥责甲骨文律师：当初不是你们要的陪审团审判吗？现在有了判决意见（虽然是部分的），你们又要我来判？

很显然，围绕“合理使用”还有很大的辩论空间。这给了谷歌新的希望。在后来的谷歌上诉，以及再后来应对甲骨文的上诉过程中，“合理使用”成为了谷歌庭辩的策略核心。

一审后面几天的争论继续围绕专利和合理使用。又经过了十几个日夜的陪审团争辩，完整的一审陪审团意见终于下达：

谷歌确实侵犯了甲骨文所持有的37个 Java API 的著作权，但没有侵犯甲骨文的专利权。

陪审团讨论的整个过程，都和人们熟悉的电影《十二怒汉》有些许相似：

最一开始，只有一名陪审员站在甲骨文这边。在长达一周多的议论过程中，他甚至争取到了另外两人的支持，僵持的投票结果一度达到9-3…...

但是，现实和电影有太多出入，这桩史诗级的科技法律案件，虽然极其复杂，案情倒也也远没有《十二怒汉》中的杀人案那般扑朔迷离；两家盈利性公司的争斗中，正义也无从谈及；那位持异见的陪审员，也没有电影中的戴维斯那样巧言善辩……两位甲骨文支持者被说服，最后一轮投票，为了达成一致，尽快结束这场“苦难”，那位陪审员也投了谷歌一边。

2012年5月底，陪审团认定谷歌翻版 Java API 的行为构成对甲骨文技术的合理使用。

一个月后，重大反转再次发生，甲骨文的最后一丝胜利的希望被法官杀死。

前序陪审团虽然认定谷歌侵犯了 Java 著作权，但 Alsup 按照自己对版权法的解读，逾越了陪审团的意见，下达了对甲骨文不利的裁决：甲骨文宣称被侵权的37个 Java API，实际上只有3%的代码来自于该公司，且不属于现行版权法保护的范畴，其余部分来自谷歌公司，因此驳回甲骨文的侵权起诉。

你可能想问：这法官好大的官威啊！凭什么敢这么做？

首先，即使有陪审团的存在，法官仍可以做出不同的判决；

其次，Alsup 的爱好之一恰好就是写代码……他在业余时间写了几十年 BASIC，还发布过几款桥牌和桌游的软件。

庭上，他曾经几次打断甲骨文律师的发言，表示自己虽然没有写过 Java，但已经能够清楚地理解相关 API 的工作原理，不需要冗长、无趣、且带有误导性的律师解读。在他的法庭上，鲜有涉世未深的 tech bro 和口蜜腹剑的律师能够蒙混过关……

谷歌乘胜追击，要求甲骨文方面负担其法务成本403万美元；后来法院判决甲骨文支付谷歌113万美元。

甲骨文方面对事实上的法官审判 (bench trial，和陪审团审判 jury trial 相对）感到不满，选择了上诉。

上诉个没完没了，高院终于被迫营业

两年后的2014年5月9日，美国联邦巡回上诉法庭的一纸判决，再次将信心满满的谷歌置于不利之地，并且为整个软件开发行业重新蒙上了一层阴影。

新判决认为，下级法院没能正确地认清案情的本质，没搞清楚它的职责到底是区分什么受著作权保护，什么不受，还是惩罚真正侵犯权益的行为。上诉法庭的意见是，甲骨文的 Java API 具有足够的原创性，受到版权法律的保护。

软件行业应该有著作权的存在，这并无问题。如果是授权模式的软件，有授权使用费的存在，该交费就交费；如果是开源软件，任何人在参考、借鉴或直接使用第三方提供的技术进行再次开发时时，都应该严格遵守许可证书，在许可的范围内合规、合理使用。

但至少对于 API 这个东西，权威专家和一线从业者都认为，上诉法庭的新判决给了甲骨文太大的好处，有失公平。

这个判决制造了一个危险的先例，任何采用现有 API 开发新产品和服务的第三方开发者，未来都有可能成为版权收费的对象，或者在无力偿付时，变成侵权者。

文字的创作者不喜欢被抄袭，代码的写作者也不愿意自己的项目被无节制的复制粘贴。但在软件领域，那些从零开始发明一个全新事物的永远只是极少数人。这个时代的软件的工作方式，决定了大多数我们所谓的创新，都是站在其它人的肩膀上，这已经是不争的事实。

但如果按照上诉法庭的裁决，开发者为了避免法务风险将不得重新发明轮子，自行开发替代现有 API 的技术，而这降低了效率、遏制了技术的互操作性，将会进一步割裂技术市场，不利于创新的发生。

2014年10月，谷歌提交申请，希望高院能够审理此案。

遗憾的是，本来有一个月时间可以做出答复的高院，用了整整大半年的时间，最后还是在2015年6月通知谷歌将不会接手此案，理由是著作权是个太小的问题，不值得接手。

按照联邦上诉法庭的判决，虽然甲骨文对 Java API 拥有著作权一事得到认可，谷歌在“合理使用”上仍然有商榷的余地，所以案件又被打回一开始的低级法庭审理。

这场旷日持久的争斗，远未结束。而早已厌倦了这个话题的人们，终于失去了兴趣。关注者越来越少，谷歌和甲骨文双方法务的劲头也没有一开始的足——这对谷歌来说反倒是件好事，因为 Android 并没有受到侵权事件太严重的影响，经过多年的发展已经成为移动计算领域的寡头质疑。

而甲骨文又能有什么坏心眼呢，不就是想要个六七十亿美元花花嘛……

苦的是低级法庭，这堆陈芝麻烂谷子又得反刍一遍，还得新招一批陪审员继续开会吵架。由于呈堂的证据和当年一样，2016年的新判决也和当年一样，新陪审团看了前辈们当年吵架的记录，站了谷歌这边。

但是精彩的地方来了：2014年驳回一审判决的那个联邦上诉法庭，在2018年又把低级法庭新陪审团达成的判决给驳回了，理由是当年的陪审团——注意，是当年哦——在“合理使用”上无法达成绝对的一致，所以打回重审的案件，压根就不应该找陪审团，应该直接法官审判。

这让谷歌找到了一个关键突破口：注意，前面我们提到，甲骨文上一次到联邦法庭上诉的其中一条理由，就是低级法庭的法官做出了和陪审团意见相反的裁决。而打回重审之后，上诉法庭也做了同样的事情。这意味着谷歌现在有足够的法律依据，可以寻求推翻上诉法庭对自己不利的判决。

2019年1月，谷歌再次上书高院要求聆讯此案。这次，高院被迫营业。

整个案件的争议性再次爆表：高院先是礼貌的问了一嘴政府在此案中什么意见，而当时的特朗普政府毫无疑问地站在了甲骨文一边，要求高院否决谷歌的请求；而另一边，却是包括微软、红帽、Mozilla、IBM 等头部利益相关者在内的上百家科技公司、组织和个人，联名上书支持谷歌。

盛情难却，高院最终同意聆讯此案，首次口头辩论定于2020年3月24日，后因新冠疫情推迟到了10月7日线上进行。

当时，大法官金斯伯格刚去世不久，接任者还未宣誓就职，高院大法官阵容只有8人，出现4-4平局的概率增大，对于谷歌稍显不利。

在10月7日的线上口头辩论中，八位大法官虽然尽力表现不偏不倚，在问讯环节中还是给人以更倾向谷歌这边的观感，就连保守派大法官戈萨奇，也没有站在甲骨文这边，而是将关注重点放在了谷歌的宪法第七修正案主张，也即联邦上诉法庭驳回低级法院陪审团裁决结果的正义性上。

高院的大法官各个都是美国法律界最权威也最受尊敬的资深人士，但同时因为关注的话题更复杂，没有一人像加州地方法院的 Alsup 法官那样，对这次的议题有什么深入的了解。他们更多依赖高院和各地法院过去的判例，以及自己对于法律的诠释去入手此案。

而为了帮助这些对 Java API 著作权和软件互操作性一窍不通的大法官们，更好地理解本案的情况以及自己的主张，谷歌和甲骨文的律师不得不使劲浑身解数，将 Java 比喻成各种各样奇怪的东西，比如一本包含了《宋飞传》万条金句的书。

甲骨文在自己回复高院的文书里就用了《哈利波特》打了一个奇怪的比方：

按照谷歌的逻辑，一个抄袭者（她）可以将JK罗琳女士的理念定义为”一个有关于哈利波特、罗恩韦斯利和赫敏格兰杰去霍格沃茨上学的故事“，然后偷走里面的角色和背景故事。她还可以推销这本畅销书的抄袭版本，并且宣称自己除了逐字重写整个故事里的11300个最令人印象深刻的句子和场景之外”没有其他的办法“，因为这些句子和场景对于读者粉丝利用他们已有的知识来说是”必要“的……

以及，这些大法官们还会时不时地自己分享一些有的很精确，有的令人啼笑皆非的比喻，比如 QWERTY 键盘、元素周期表、数学题解法、餐馆菜单、如何爆窃保险柜等……

首席大法官罗伯茨质问谷歌律师：

“你知道，爆窃保险柜可能是你得到钱的唯一办法，但那并不意味着你可以做这件事。我的意思是，如果有且只有一个方法的话，那也应该是去申请一张许可证。”

谷歌律师机智地借用这个比喻回应了大法官：

法官大人，我认为这个比喻正好能够帮助我方。您可以这样看：如果您拿着一张保险箱的专利，确实能够阻止我们进入。但是，如果您现在是要写一本教人如何爆窃保险箱的说明书，那并不意味着您拥有这样做的独家特权。

最有趣，对于非技术人士也最容易理解的一个比喻，来自（支持谷歌的）大法官布雷耶。他将 Java API 比喻成 QWERTY 键盘，或者更具体来说，QWERTY 作为一种键盘的布局：

我是这样看的，如果你将它比喻成 QWERTY 键盘。一开始的打字机确实不需要有 QWERTY 键盘，但是，我的上帝啊，如果你允许某人拥有 QWERTY 键盘的著作权的话，他不就掌控了全世界所有的打字机了吗？而这跟著作权压根不应该有关系啊。

如果你对这些比喻感兴趣的话，GitHub 用户 kemitchell 汇总了这次长达一个半小时的口头辩论中出现过的所有主要的比喻（可能漏掉了几个次要的），以及辩论的录音和速记文档。文末可以找到链接。

知识产权律师 Matthew Lane 发推表示，某些比喻似乎并没有消除法庭上的疑惑，反而制造了更多的混乱。法学教授 Sarah Burstein 开玩笑说：我的预测是，谁的比喻更厉害，谁就能赢下这场官司……

时间快进到4月5日周一，高院终于在长达半年的审理期后，推翻了前序上诉法庭的意见，重新做出了对谷歌有利的全面裁决。不仅在”合理使用“的争议话题上认定谷歌对 Java API 的复制属于合理使用，还认定谷歌并没有侵犯甲骨文的著作权。

大法官布雷耶在意见书中写道：

作为计算机界面的一部分，这些复制过来的代码，从根本上与不在著作权范畴的理念（API 的组织方式），以及新的创意表达的创造（谷歌独立撰写的代码）绑定在一起。和很多其它电脑程序不同，这些复制的代码的价值显著体现在对于那些已经了解此 API 系统的用户（程序开发者）的投资上。考虑到这一显著差别，（谷歌的）合理使用行为并不会对国会立法保护的电脑软件著作权益造成损害。

谷歌对甲骨文 Java API 有限的拷贝行为属于一种变革性的使用。谷歌仅仅拷贝了一部分代码，从而帮助程序员在不同的计算环境下，不放弃已经熟悉编程语言，仍能够继续工作。的一部分代码。谷歌此行为的目的是创造一个不同的计算环境（智能手机）并且创造一个软件平台（Android）来帮助实现这个目标。法庭记录通过多种方式显示，谷歌重新开发 API 的行为能够进一步帮助开发计算机程序。因此，谷歌此行为的目的是符合著作权的法制目标的。

值得注意的是，大法官布雷耶也澄清，判决中关于合理使用的部分，仅适用本案中所提及的 API 这一计算机技术类别，并不推翻高院此前对于其它著作权案件的判决结果。

总的来说，高院的这一判决，给关注这起旷日持久案件的开发者们，打了一针强心剂：

”在我们看来，这一判决的重要意义，在于合理使用原则可以在确定计算机程序版权的合法范围方面发挥重要作用。合理使用原则可以帮助区分不同的技术，区分计算机程序代码中的表达性和功能性。

同时，这一判决也给版权流氓敲响了警钟：

“合理使用的原则，既可以激励版权拥有者创作内容从而获得合法收益，也可以避免过度保护版权的行为对其它市场和产品产品的开发造成损害。换句话说，合理使用原则可以完成它的基础使命，在类似案件中提供一种基于整体情境的制衡，将版权垄断者限制在法律许可的范围之内。

地址：

https://github.com/kemitchell/writing.kemitchell.com/blob/master/_posts/2020-10-12-Oracle-Google-Metaphors.md

https://www.supremecourt.gov/oral_arguments/audio/2020/18-956