谷歌有限责任公司诉甲骨文美国公司案（Google LLC v. Oracle America, Inc.），593 U.S. ___ (2021)，[1]是一起以计算机程序性质为焦点的著作权法案件。该案的诉争对象是Java编程语言的部分应用程序接口（下简称API），以及大约11,000条源代码。这些接口及代码最早由Sun系统公司所开发，目前甲骨文公司通过其附属的甲骨文美国公司对其享有著作权。谷歌在其开发的安卓（Android）操作系统的早期版本中使用了上述接口及代码，但是在后来发布的安卓版本当中不再使用上述有著作权负担的源代码。至于甲骨文的API，谷歌虽承认存在使用行为，但主张其构成合理使用。
| 谷歌有限责任公司诉甲骨文美国公司案 | |
|---|---|
 | |
| 辩论：2020年10月7日 判决：2021年4月5日 | |
| 案件全名 | 谷歌有限责任公司诉甲骨文美国公司案（Google LLC v. Oracle America, Inc.） |
| 诉讼记录号 | 18-956 |
| 引注案号 | 593 U.S. ___ |
| 既往案件 |
|
| 后续案件 | On remand, Oracle Am., Inc. v. Google LLC, No. 2017-1118, 2021 WL 1941874 (Fed. Cir. May 14, 2021) |
| 提出问题 | |
| |
| 法庭判决 | |
| 谷歌对Java SE应用程序接口的复制，以内容上仅使编程人员得以将其积累的知识运用于新的、具有转换性的程序为限，在法律上构成对该接口的合理使用。 | |
| 最高法院法官 | |
| 法庭意见 | |
| 多数意见 | 布雷耶 联名：罗伯茨，索托马约尔，卡根，戈萨奇，卡瓦诺 |
| 不同意见 | 托马斯 联名：阿利托 |
| 巴雷特没有参与该案件。 | |
| 适用法条 | |
| 17 U.S.C.§102(b)；17 U.S.C. §107 | |
甲骨文公司发起诉讼，认为API属于受著作权保护的内容，并以此为由主张谷歌赔偿该公司88亿美元，作为销售侵权软件及许可费的赔偿。虽然在地方法院的两次诉讼中，陪审团都作出了有利于谷歌的裁决，但联邦巡回区上诉法院推翻了这两项判决，宣称API受著作权保护，谷歌在安卓中使用甲骨文的API不属于合理使用范围。谷歌于2019年向美国最高法院提出上诉，最高法院同意于2019工作年度就接口是否受著作权保护及合理使用的问题对本案进行审理。由于2019冠状病毒病疫情，本案的审理被推迟到2020年度。2021年4月，美国最高法院以6票对2票的比例作出判决。在假定API受著作权保护的基础上，法院就合理使用原则的四个要素对谷歌的行为进行审查，认定四项的结果都倾向谷歌。因此，法院推翻了上诉法院的裁决，并将案件发回重审。[2]
许多计算机程序和软件库（尤其是开源的程序）在开发过程中都利用了来自商业程序或竞争对手的API。开发者重新设计接口的功能，以便实现不同系统或平台之间互操作性的要求。因此，本案对于科技和软件行业具有重大意义。
背景
Sun系统公司从1990年12月起开始开发Java系统。[3] 该系统包括一种新的编程语言，一台虚拟机，以及一组用于处理该语言的函数库。[4]通过API，编程人员得以调用函数库，获知其应该向库函数提供哪些信息，可以期望获得什么结果。因此，他们不必再耗费精力研究他们所用的函数库如何实现其功能。通过这些函数库的共同作用，程序员就可以在Java虚拟机上编写并运行程序。就通常方式而言，在任意的Java虚拟机上运用一套通用的函数库，即可满足互操作性的要求。正如Sun所标榜的那样：“编写一次，运行无阻（write once, run anywhere）”，程序员只需要创建一种版本的软件，便可依托一组通用于所有Java虚拟机的接口，在所有支持Java的计算机平台上运行。
Java语言于1995年向公众公布。通过“Sun社群代码许可”（Sun Community Source License），源代码可以免费使用。但是，使用了Java源代码的程序必须遵守Java的编程规范，商业性改编程序必须要得到Sun的许可。[5][6]虽然人人都可以运用该语言编程，Sun仍将标准版Java平台（Java SE）和微缩版Java平台（Java ME）的函数库作为预先编译的Java字节码，附带其API一并提供给用户，同时提供技术兼容性包（TCK）以检查特定的实现是否符合Java的规范要求。[7]
2006-2007年间，来自编程人员越来越大的压力迫使Sun改变了多种Java包的许可方式：使用带有类路径例外的GNU通用公共许可，向开发人员开放了创作改编程序所必要的权限，并赋予其在不同许可下发布应用程序的能力。这些改变的结果是，Sun于2007年首次发布了开源版的Java开发组件（OpenJDK）。Sun仍然保持了对语言和标准本身的高度控制，并且向商业用户授权TCK等必要组件。[6] 与此同时，Sun转变了其商业模式，与诺基亚、摩托罗拉、Research in Motion（即后来的黑莓公司）等企业签署了许可协议。[8]
2003年，安迪·鲁宾、里奇·迈纳、尼克·希尔斯和克里斯·怀特基于发展手机平台的目的创立了安卓有限公司。[9][10]谷歌于2005年收购了安卓公司。[10]在安卓系统的开发过程中，谷歌希望能够加入Java SE的函数库。谷歌的执行董事长埃里克·施密特与Sun的总裁乔纳森·I·施瓦茨就Java函数库在安卓系统中的运用进行了谈判。Sun的许可费要价在3000-5000万美元之间。施密特表示谷歌本来愿意付许可费，但对Sun共同控制安卓系统的要求感到顾虑。[11][12][13]根据谷歌方面的说法，Sun希望对安卓系统能有更多的掌控权，对安卓系统的语言进行开源，让第三方能够更好利用其代码。[11]甲骨文公司则声称，Sun之所以拒绝提供许可，是担心谷歌会以分叉的方式创造谷歌专用的Java语言，导致与其他运用Java语言的程序无法互操作。这种行为无疑是对Java语言赖以立足的“编写一次，运行无阻”原则的“咒诅”。[14]
在这段时间，Sun提供的OpenJDK服务仍不像Java SE版本那样成熟完备。谷歌没有寻求Java的使用许可，而是以净室设计的方式开发了一套Java SE的函数库——也就是说，谷歌在不接触Sun的源码的前提下，完全从头开始开发了一套代码。这些库构成了安卓的Dalvik虚拟机的内核。从虚拟机的一部分当中可以发现37个API以及大约11500行被认为在Java中占有核心地位的代码。这些代码来自于Apache Harmony项目，该项目由Apache软件基金会(ASF)主导，旨在提供净室的Java开源实现。在此之前，Apache基金会曾试图向Sun寻求许可，使Apache Harmony成为官方支持的Java实现方式，但出于其所使用的Apache许可与Java的GNU许可不兼容以及其他原因，未达成一致。Apache试图获取Java TCK的权限，以便利用Sun自己的实现方式对Harmony项目进行验证，也未能成功。[15][16]谷歌曾声称其使用Apache的代码是为了保障满足编程者对其系统与Java SE互操作性的要求，但在第二次上诉庭审当中，谷歌又表示，其使用这些代码是出于其商业考虑，希望能尽快完成安卓系统，避免无谓地重新开发代码。2011年，Apache基金会不再维持对Apache Harmony的控制，谷歌接管了对这些库的控制权。
2007年11月5日，谷歌发布了安卓平台的测试版，并在一周后发布了其软件开发工具包，在工具包当中他们载明使用了Java的某些技术。[17][18][19]同一天，Sun的总裁施瓦茨向谷歌表示祝贺。[20]庭审期间，施瓦茨表示，尽管他们在安卓发布的时候就知道谷歌可能规避了他们的许可要求，他们仍然“决定咬牙支持安卓，让所有支持安卓的人都知道，我们与他们共享同样的价值观。”[8]
2009年4月，甲骨文宣布了其收购Sun的计划；收购于2010年1月完成。[21]Java语言让甲骨文得以打入硬件行业。甲骨文的首席执行官拉里•埃里森更是将Java语言称作“我们所买下的最重要的软件资产”。[22]在收购Sun之后，甲骨文继续发展Java，并且寻求发放许可的机会。
2013年，谷歌发布了安卓系统的4.4版本（KitKat），以Android Runtime作为运行时库，取代了Dalvik虚拟机。Android Runtime由谷歌自己研发，与Java的源码毫无关系。[23]但是，直至诉讼时为止，安卓仍然在继续使用Java SE的API。直到2016年发布的新版本Android Nougat操作系统中，谷歌才完全将经由Apache Harmony渠道获得的代码换成了开源的OpenJDK代码。[24][25]
依据1976年修订的美国著作权法，计算机程序属于文字作品的一种，只要具有独创性且被固定于有形的表达载体，即受到著作权法的保护。
与其他类型作品一样，对计算机程序的保护不仅限于字面复制。程序的“结构、序列与组织方式”（structure, sequence and organization，简称SSO）同样受到保护。但是，对非字面元素的保护受到相当大的限制。除了公有领域的内容以外，仅具有功能性的内容也不受保护。但这一边界存在模糊性。在1996年的莲花公司诉宝蓝公司案当中，最高法院以4票对4票的平局默认了下级法院关于用户界面不受著作权保护的结论，但未形成有说服力的判例[26]（用户界面目前可通过专利保护）。在1992年的CA科技公司诉Altai公司案中，联邦第二巡回上诉法院开创了“抽象—过滤—比较测试法”（Abstraction-Filtration-Comparison test）[27]，以区分受著作权法保护的内容与不受著作权保护的仅具有功能性或者是位于公有领域的内容。当然，通过计算机程序呈现的图文、声音等仍然可以作为视听作品保护。
依据现行美国著作权法，出于包括批评、评论、新闻报道、教学、研究等在内的目的而使用他人作品的合理使用行为不侵犯著作权。在个案判断是否为合理使用时，必须考虑到下列因素：（1）使用的目的和性质，包括这种使用是具有商业性质或者是为了非营利的教育目的；（2）有著作权作品的性质；（3）同整个有著作权作品相比所使用的内容和数量；以及（4）这种使用对有著作权作品的潜在市场或价值所产生的影响。[28]
在后来的司法实践中，使用的目的和性质在多大程度上具有“转换性”（transformative）往往受到极大关注。在1994年的坎贝尔诉阿卡夫-罗斯音乐公司案中，尽管嘻哈组合2 Live Crew对罗伊·奥比森名曲《噢，美丽女人》（Oh, Pretty Woman）的戏仿具有营利性，联邦最高法院仍然认定该行为具有转换性，构成合理使用。[29]因此，仅证明复制行为具有商业目的，不一定能说明该行为不是合理使用。
第一阶段诉讼：API的著作权法属性及专利法的适用
本案的第一阶段从2010年起一直持续至2015年。甲骨文关于API可受到著作权保护的主张获得了支持，但其关于专利侵权的主张则遭到拒绝。
2010年8月13日，甲骨文向加利福尼亚北区联邦地区法院起诉谷歌侵犯著作权及专利权。依据甲骨文方面的说法，谷歌在明知没有Java许可的情况下仍坚持开发安卓系统、挪用Java的API，构成对甲骨文著作权的侵犯。甲骨文同时引证其名下7个由Sun开发、与Java相关联的在先专利。其认为，谷歌在雇佣Sun公司的前雇员开发安卓系统时本应留心这些专利。因此，甲骨文一方面主张金钱赔偿，另一方面也主张针对谷歌使用涉侵权材料的行为下发禁制令。[30][31]
本案被交由威廉·阿尔索普（William Alsup）法官审理。他将本案分为三部分处理：著作权问题，专利问题及损害赔偿。
著作权问题的诉讼于2012年4月16日开始。这一阶段的诉讼包含以下几个相互独立的侵权请求：一条九行长的rangeCheck函数式，若干个测试文件，Java (API)的结构、序列及组织方式，以及API文档。
甲骨文主张，谷歌经由Apache Harmony项目所得的37条API数据均构成侵权。[12] 经过两周质证后，陪审团于2012年5月7日作出认定，认为谷歌就API的代码、SSO及文档而言均满足侵权的要件。但是，就谷歌的行为是否属于合理使用，陪审团内部未能达成一致。陪审团同时认为，尽管Sun及甲骨文的行为可能为谷歌创设了不需要向前者申请许可的信赖，但谷歌在开发安卓系统的时候实际上并未依托上述信赖。[32]甲骨文方面向法院请求依法裁决（judgement as a matter of law, JMOL），在陪审团未达成一致的情形下对谷歌的合理使用抗辩不予受理，并推翻陪审团关于8份安全性相关文件不侵权的认定（虽然陪审团认定不存在侵权，但谷歌在诉讼中承认存在字面复制）。阿尔索普法官同意了上述请求。谷歌就rangeCheck函数式的问题提交了一份类似的依法裁决请求，但遭到了法官的拒绝。[33]
专利问题的诉讼于2012年5月7日开始。[34]诉讼涉及甲骨文的两项专利：6,061,520号专利（执行静态初始化的方法及系统）[35]，以及RE38104号专利（解析数据引用的方法及设备）[36]。谷歌主张了不侵权抗辩：针对前一专利，谷歌认为，其使用语法分析是为了静态初始化的优化，而非专利所涉的“模拟执行”；针对后一专利，谷歌认为其指令并不包含符号引用。本阶段诉讼的陪审团成员与著作权阶段诉讼相同[34]；2012年5月23日，该陪审团就全部专利侵权主张均作出了不侵权的认定。[37][38][39]
2012年5月31日，阿尔索普法官就前两阶段的诉讼作出了最终判决。与陪审团就API所作的认定不同，他认为API并不属于著作权法的保护范围：
“在著作权法的框架下，只要用于执行方法的特定代码是不同的，则人人皆可任意编辑其自己的代码，以实现Java API所涉方法能够实现的功能与要求。即使声明代码或方法的标题行是相同的，亦无关紧要。”[12]
阿尔索普法官同意陪审团关于rangeCheck函数与8份安全文件存在著作权侵权的认定，但裁定甲骨文仅得以主张不超过150,000美元的法定赔偿。[40][41]
经由上述裁决及案件双方的协商，裁定赔偿金的诉讼阶段不再开启。2012年6月，双方同意，谷歌就涉嫌侵权的小部分代码无须支付法定赔偿金。[42][43]
地区法院审理结束后不久，双方均就阿尔索普法官裁决中未予受理的部分请求依法裁决，结果，甲骨文就该裁决提出上诉，谷歌则就字面侵权问题提出交叉上诉。由于该案涉及专利问题，上诉自动交由联邦巡回区上诉法院管辖。[44][45]案件于2013年12月4日进行了审理。[46][47] 2014年5月9日，上诉法院给出了判决。[48]
上诉法院认为，著作权法为一切“固定于有形表达载体中的独创性作品”提供保护。依据立法历史解释，著作权法中的文字作品也包括“计算机程序，只要其凝结了编程人员超出思想而构成独创表达的创作”。独创性是著作权法提供保护的首要条件。所以，法院“首先审查该表达是否为编程者独创”，而在这一问题上谷歌已然承认自己的不利地位。法院由此得出结论，认为“甲骨文的API软件包整体是新颖的、独创的，（其法律地位）类似于分类表”，推翻了地区法院关于API的结构、序列及组织方式不受著作权保护的结论。就谷歌提出交叉上诉的字面侵权请求，法院同样作出了对甲骨文有利的判决，认为该复制行为并非“可忽略不计”之过。上诉法院将案件发回地区法院进行重审，以确定谷歌的使用行为是否适用合理使用抗辩。[48][49]
第二阶段诉讼：合理使用
根据上诉法院的指令，地区法院于2016年5月9日再次开庭，在API受到著作权保护的前提下，审理谷歌的行为是否属于合理使用。[52][53]2016年5月23日，双方完成最终陈述，陪审团开始审议。甲骨文主张的赔偿额高达90亿美元。[54][55][56][57][58][59]2016年5月26日，陪审团认定安卓系统当中实现的37个Java API为合理使用，不构成对甲骨文的侵权。[60]甲骨文宣布将会上诉，[61]但在此之前，其先是提出否决陪审团认定的依法裁决请求，[62]后又请求重新审理，[63][64]但均未获成功。2016年10月26日，甲骨文正式提起上诉。[65]
联邦巡回区上诉法院于2017年审理了甲骨文的上诉。2018年3月27日，法院作出了有利于甲骨文的裁决。[66]
判决首先分析了法官和陪审团在审判合理使用问题时分别应起的作用；接着将关注点聚焦于其假定陪审团已然解决的事实问题，以及这些事实问题对法律问题的影响。[66]上诉法院指出，在类似本案这种事实和法律问题相混合的案件中，陪审团的作用仅限于对事实做出决定。上诉法院应当审查陪审团采取合理标准所应得的结论是否与实际认定的结论相符，以及下级法官的裁决在法律上是否正确并合理。对法律与事实混合问题的标准审查涉及三部分：“一、确定案涉问题应适用的法律标准，以及与该标准相关的事实的类型；二、找出现有案件已掌握的事实；三、评估所发现的事实是否通过与涉案问题相应的法律测试。”
判决未再讨论事实问题，而是直接认定，谷歌逐字复制了37个Java API包的声明代码及11,500行受著作权保护的代码，同时也复制了Java API包的结构、序列及组织方式。谷歌亦承认复制的软件具有创造性和原创性。就法律问题而言，上诉法院综合衡量了既有认定合理使用的四项标准，并认为，即使陪审团决定的所有事实都对谷歌有利，谷歌对Java代码的使用仍不属于合理使用。
- 就涉案行为的目的及性质而言，谷歌的使用不符合“转换性使用”的要求，因为其使用目的与著作权人原有的使用相同，甚至没有些微的更改或重写。即使从建立新平台的意义上说，安卓系统的使用也没有转换性，因为市场上早有其他基于Java的智能手机。
- 就著作权作品的性质而言，上诉法院暂且采纳了陪审团的认定，认为API包虽具有一定新颖性，但其同样具有相当的功能性，由此应作出对谷歌有利的判决。尽管如此，法院援引了联邦第九巡回上诉法院的意见，认为这一要素在合理使用的权衡中并不具决定性。法院认为，过于强调这一要素将与国会立法长期以来对软件著作权的保护态度相冲突。
- 该使用不满足最小限度复制的要求，因为在被复制的11,500行代码中，只需要170行即可实现谷歌的目的。即便将第三方互操作性的问题纳入考虑，法院仍然认为，谷歌并未做出实质性的努力以实现第三方互操作性的目的，甚至试图隔断安卓系统与其他Java项目的互操作性。[14]
- 这种使用可能对Sun和甲骨文的市场造成损害，因为可以预见，甲骨文将不得不与一款由自己所属计算机语言派生所得的免费产品开展价格竞争，付出大幅折扣以及本不期望的合同条款作为代价。
与谷歌的合理使用主张相反，法院认定，谷歌的行为一方面意在加强其安卓平台对通常熟悉Java的现有开发人员的吸引力，另一方面也是为了避免重写代码的重复劳动——他们本应这么做，而且真正实现API功能的代码仅占了170行。法院指出，仅仅“让自己变得轻松”，显然不属于合理使用的有效理由。同时，安卓向公众免费提供的事实也不能改变谷歌商业性使用目的的认定。[67] Oracle甲骨文有专门用于吸引程序员的许可计划及商业化的平台，向希望在竞争性平台中使用API或将其嵌入电子设备的人收取许可费。为贯彻“编写一次，运行无阻”的理念，甲骨文对被许可方提出了严格的兼容性要求。[68]
最终，上诉法院将案件发回地方法院，以确定谷歌应支付给甲骨文的损害赔偿金额。[67]
最高法院
谷歌于2019年1月向美国最高法院提交了调卷令状请求，挑战上诉法院作出的两项有利于甲骨文的裁决。谷歌将本案的重点集中于：API等软件接口是否受到著作权保护，以及谷歌对Java API的使用是否如同陪审团认定的那样属于合理使用。[69]在2019年4月的一份判令中，最高法院要求美国司法部副部长提交一份法院之友意见书，以概述政府对本案的立场。[70]特朗普政府支持甲骨文，敦促法院拒绝颁发调卷令。微软、Mozilla公司、红帽公司等企业则提交了支持谷歌的意见书。[71]IBM、计算机与通信行业协会、互联网协会、汽车维护协会以及由超过150名学者和计算机专业人士组成的团体也提交了支持谷歌的意见书，警告称，有利于甲骨文的判决将整体性损害计算机行业。[72]
最高法院于2019年11月15日批准了调卷令，原本预定于2020年3月24日审理此案。[73][74][75]但由于COVID-19流行，最高法院于2020年3月16日推迟了3月的庭辩日程；并于后来宣布将包括本案在内的几个案件由2019—20年度推迟到2020—21年度的第一周审理。[76][77][78]鉴于联邦地区法院曾推翻陪审团的事实认定，最高法院后来又要求各方就谷歌提出的第七修正案问题另外提交意见书。[79]
最高法院于2020年10月7日听取了口头辩论。由于COVID-19持续流行，口头辩论通过电话会议进行。[80]露丝·贝德尔·金斯伯格法官在此前一个月去世，其继任者埃米·科尼·巴雷特法官的任命尚未被确认，因此巴雷特法官并未参与本案。[81]依据对庭审的观察报道，法官在著作权问题上似乎支持甲骨文，但他们也尊重微软支持谷歌的论点（微软的意见书辩称，倾向甲骨文的裁决可能会颠覆软件行业）。法官们的部分问题亦聚焦于著作权法的思想—表达二分原则以及合并原则如何适用于API。尼尔·戈萨奇法官还重点关注了第七修正案的问题，以及联邦巡回区法院推翻陪审团裁决是否正确的问题。[80][82]
最高法院于2021年4月5日，以6票对2票的多数判决谷歌对Java API的使用属于合理使用，推翻了联邦巡回区上诉法院的判决，并将案件发回进一步审理。斯蒂芬·布雷耶法官撰写了法庭多数意见。
判决认可了上诉法院关于合理使用审查的意见，认为合理使用兼具事实问题和法律问题两面性，陪审团仅认定事实问题，但能否根据事实得出合理使用的结论仍然由法官决定。也因此，上诉法院推翻陪审团裁决的行为与宪法第七修正案“由陪审团裁决的事实……不得重新审查”的规定并不冲突，谷歌要求由陪审团对合理使用作最终决定的主张没有法律依据。
布雷耶假定API受到著作权保护，进而直接对衡量合理使用的四个因素进行了审查：[83][84]
- 受著作权保护作品的性质：布雷耶认为，API仅作为声明代码而非具体的实现，在著作权法的语境下，它发挥类似于杜威十进制图书分类法的“组织功能”，这一性质导致合理使用更易适用。[85]
- 使用的目的和性质：布雷耶表示，谷歌使用并改造Java API的行为“目的在于扩展基于安卓系统的智能手机的功能和实用性”，而这“创造了一个能让程序员轻松使用的新平台”。[84]他还写道，谷歌对Java API的使用“仅以实现智能手机程序的实用性所需为限”。[84]
- 被复制受保护内容的数量和实质性：布雷耶认为，谷歌只使用了大约0.4%的 Java源代码，可忽略不计。针对实质性的问题，他写道，谷歌没有复制Java实现功能所需的核心代码：“谷歌复制这些代码，不是因为它们多么有创造力或多么美观，甚至（某种程度上）也不是因为它们自身的目的。谷歌复制这些代码只是因为程序员已经习惯了使用Java SE，如果没有它们，将很难……吸引程序员使用……安卓系统。”[84]
- 复制行为的市场效应：布雷耶认为，谷歌在复制Java API时，尚不清楚安卓系统是否会成功，安卓系统不应被视为 Java 的替代品，而应为在不同平台上运行的产品。[84]布雷耶进一步表示，如果判决支持甲骨文，“可能会对公众造成威胁”，因为“只有甲骨文将掌握关键内容。这一结果很可能为甲骨文（或其他拥有计算机接口著作权的公司）带来极高的利益。……（但是）这种控制力与作为著作权法基础的激励创造的目标相冲突，而不是进一步助益该目标。”[83]
布雷耶就此认定，谷歌对API的使用满足所有四个因素的要求，谷歌的使用“只是允许用户将他们积累的才能用于新的转换性的平台所必需的”。[83]既然谷歌的复制行为构成合理使用，没有违反著作权法，[81]那么认定API是否受著作权保护亦不再必要。
克拉伦斯·托马斯大法官撰写了一份反对意见，塞缪尔·阿利托大法官亦联名支持该意见。[86]托马斯写道，多数意见在实施代码和声明代码之间划分了一种国会立法者未曾允许的区别，进而，“这种扭曲的分析导致了以下结果：很难想象声明代码还能在什么情况下受到著作权保护。”[24]他进一步表示，在他自己的合理使用分析下，“谷歌对受著作权保护代码的使用绝非合理。”[87]
影响
谷歌与甲骨文的诉讼为科技行业密切关注。鉴于API的大量使用，如果司法判决有利于甲骨文，可能对过去和未来的软件开发都产生重大影响。[88]包括谷歌及其他基于安卓系统的开发人员在内，反对上诉法院判决的人或是从互操作性、对软件创新的影响等各方面提出了他们的担忧，或是指出，既有接口的著作权人可能以其权利恶意挟持那些善意信赖相应标准开放性的下游开发者。如果API受到著作权保护，下游企业将不得不故意采用不兼容的标准以免面临复杂的诉讼风险。而这与当前的行业趋势——提高不同服务之间的互操作性，允许程序之间的交流，为终端用户建设更加一体化的平台——是不兼容的。[69][89]
《连线》杂志以Linux操作系统为例：Linux是完全开源的，但它所采用的POSIX是一套模仿Unix操作系统以实现高度互操作性的API。编程人员只需要编写一组代码，就可以在具有相同API的任何系统上编译，即使系统的计算架构不同。如果甲骨文胜诉，则Unix的当前所有者Micro Focus公司可能会向所有试图将基于POSIX的操作系统的开发者寻求赔偿。[90]
行业和法律专家们担忧甲骨文的胜利可能会对软件开发产生寒蝉效应：著作权所有者将得以阻止对API实施反向工程、开发可以互操作的替代产品，而这种做法在开源软件开发中很常见。[91][92][93]但专家同时担心，对谷歌有利的判决会削弱对代码开发者的著作权保护，让资源丰富的企业能轻易开发改进小企业的产品，减损对行业创新的激励。[94][95]
参考文献
外部链接
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
