应用程序编程接口“可版权性”的否定

摘要：应用程序编程接口对实现软件之间及软件与操作系统之间的互操作至关重要，在软件行业中具有重要地位。接口是否具有可版权性这一问题，在美国经历了由争议到共识，再到共识被推翻的过程。应用程序接口可版权性涉及软件保护范围的基础性问题，无论是适用版权法“合并”规则，还是考虑接口本身的“互操作”功能，兼及考量软件产业的创新发展和有效竞争的需要，均应排除应用程序编程接口的可版权性。

关键词：接口；合并；互操作性；功能性；可版权性

中图分类号：D 923.4文献标识码：A文章编号：1003-9945（2020）05-0033-08

一、问题引入

目前正在美国进行的甲骨文公司与谷歌公司的涉及应用程序编程接口（Application Programming In？ terface， API）①的版权纠纷，被业界称为“版权十年争讼”[1]及“史诗级版权诉讼”[2]。该案件吸引了软件行业从业人员及行业组织、计算机软件专家、知识产权学者等的广泛关注。受到关注的原因固然与诉争双方的行业领军地位和诉讼标的巨大有关，但更深层次的原因在于，此案涉及应用程序编程接口可版权性问题的判断，即应用程序编程接口是否是版权保护的对象，以及对其使用构成侵权抑或合理使用问题。这一问题在版权法上的结论，将在一定程度上对美国软件行业应用程序编程接口的编写及运行生态产生深远影响，也将对软件产业生态带来巨大的不确定因素。美国软件行业对世界软件行业更是具有绝对的影响力，软件产业领域核心的操作系统、中间件和数据库大多为美国企业所占领；而在操作系统方面，微软的Windows和苹果的MacOS占据全球市场97%的市场份额[3]。因此，美国软件政策的影响力从来不局限于美国境内。美国在全球推动的关于软件的知识产权保护，更使其软件产业政策对国际社会及其他国家的软件政策也会产生直接或间接的重要影响。可以说，包括对应用程序编程接口在内的美国软件政策，将极大影响其他国家应用程序接口的版权保护规则及软件产业政策。

目前，国内关于研究应用程序编程接口的文献论述较少，这与我国基础软件薄弱地位有一定关系。本文从梳理美国典型应用程序接口版权争议入手，并重点分析甲骨文与谷歌版权案的接口可版权性问题，从而探寻美国软件接口影响可版权性的底层因素，思考版权基本原理在软件作品下的具体应用，结合促进创新和反垄断目的，得出应用程序接口应不具有可版权性的结论。

二、接口版权保护历程中肯定与否定的纠结

应用程序接口的可版权性问题属于软件版权保护的范畴。利用版权进行软件保护，始终有一个难题，即计算机软件的功能性，也即“思想”与软件的“表达”之间的界限。计算机软件的功能性本质造成了在被侵权时确定版权保护范围的最大困难[4]。在应用程序编程接口中，该功能具体体现为不同软件之间及软件与硬件之间的互相可操作性（interoperability）②，这成为应用程序接口能否得到版权保护的关键。基于应用程序接口发挥的“互相可操作性”的重要作用，有学者将其有关的版权争议称之为“战争”，并认为关于软件接口版权保护，存在两场“战争”，两场“战争”的分割点就是自2010年发生的甲骨文公司对谷歌公司的接口版权诉讼。第一场“战争”发生在1980年代早期至1990年代中期，第二场战争是以2010年甲骨文公司对谷歌公司提起软件编程接口（API）侵权诉讼为起点[5]。而在两场“战争之间”，即1992年至2010年之间，美国联邦上诉法院普遍认为，实现程序之间“互操作性”所必需的软件接口不受版权法的保护。这些裁决使API使用者没有必要因为使用他人API而提出合理使用的抗辩[6]。

（一）应用程序接口不受版权保护共识的形成

第一场“战争”关于应用程序编程接口（API）是否具有可版权性的争议，主要发生于美国法庭处理的相关案例中，具体结果体现于各接口案件法院所做出的裁决。具体而言，在美国各涉及软件接口案件的法院裁决并不统一，但有一个大致演变的路径。应用程序接口的编写，往往体现了程序员的智力劳动，具有相当程度的独创性，构成版权法上保护的对象。但能否得到保护，又要受到其他因素的制约，如是否具有功能性，是否形成思想与表达的合并等。而软件本身即具有“实现某一功能”的特征，使其不同于一般作品。软件本身具有的技术特征，且其运行必然要实现一定的功能，使得在软件保护过程中，如何进行功能与表达上的界定划分，直接涉及到其能否得到版权的保护。而软件接口的互联互通的中介转译功能，也被称为“互操作性（interoperability）”，使得对这一问题的判断更显复杂。

初期的案件并没有因为“互操作性”功能而否定可版权性。在“Apple Computer诉Franklin Computer”案[6]中，“互操作性是一项商业和竞争目标，不涉及某种特定思想和表达是否合并的某种形而上学的问题”。在这种推理下，应用程序接口（Interface）并未因其具有“互操作性”而被排除出版权保护范围。在“Whelan Assocs.诉Jaslow Dental Lab.， Inc.[7]”案中，美国第三巡回上诉法院认为版权保护计算机程序的所有方面，而不保护其基本目的，这种广泛的版权保护有助于软件公司提升动力去开发软件。法院的这种观点是单纯从对创作者进行激励的角度进行推理的结果，忽略了版权具有的公共政策因素，因此，也引起很大争议。这个裁决开启了保护过严的时期，因功能性而得不到版权保护的情形只在极少数情况下发生。涉及“互操作性”软件版权法发展的关键转折点发生在1992年的美国第二巡回法院审理的“Comput？ er Assocs. Intl v. Altai”案[8]。该案对上述Whelan的判决采否定态度，法院认为，根据美国1976年版权法第102（b）条的规定，版权不得扩展到兼容性所必需的程序元素，并基于兼容性功能对有关软件不予版权保护。Lotus Dev. Corp. v. Borland Intl， Inc[9]是谷歌公司为了支持自己关于涉案接口不受版权保护的观点所援引的案例，谷歌公司认为自己的案件与该案具有法律问题上的相似性，即根据第102（b）条，用于执行计算机程序代码的命令结构是否受版权保护，这涉及到思想与表达的界限问题。该案中，第一巡回法院认为，Borland所使用的Lotus公司的接口只是一种“操作方法”，因此不受版权保护。该案已经成为具有软件保护方面里程碑式的判例。谷歌认为，第一巡回法院关于Lotus诉Oracle裁决判断逻辑可以直接应用于其与Oracle的争议。在谷歌公司看来，Java API调用的Java平台的“操作方法”，其方式Borland使用与Lotus 1-2-3的电子表格软件菜单项的操作方法完全相同。据此，以此案作为自己主张的先例依据。而在第九巡回法院的“Sega Enterprises Ltd. V. Accolade，Inc.”案[10]中，第九巡回法院认为，即使涉及复制整个代码，这也是一种合理的使用方法，因為必须进行复制才能访问接口组件，第九巡回法院认为这是不可保护的，并认为“因为Accolade拥有获得这种访问权的合法权益（以便确定如何使其盒式磁带与Sega Gene？ sis控制台兼容）”，所以复制代码以复制接口组件是一种合理的做法。

在以上案例处理的过程中，逐步形成了对应用程序编程接口在实现应用程序之间进行“互操作”的功能认可，因此，应用程序编程接口的功能性是毋庸置疑的[11]。相应的，对于为实现软件“互操作性”目的的应用程序编程接口不应成为版权保护对象已成为共识，这也意味着第一场“战争”的结束。

（二）基于甲骨文诉谷歌版权案API版权保护观点的分裂

第一场“战争”形成的编程接口不受版权保护的共识持续了数年，随着2010年开始的“甲骨文诉谷歌应用程序编程接口版权”案，第二场“战争”开始。该“战争”的二审结果，恰恰挑战了以往对于应用程序编程接口（API）不受版权保护的认知，引起广泛关注，这也成为被称为第二场“战争”的原因。在甲骨文诉谷歌软件版权侵权案件中，双方在案件事实方面并没有争议，即谷歌复制了37个Java API软件包，包括其中的“声明代码（Declaring code）”和整体的“结构、次序和组织（Structure， Sequence， and Organization， SSO）”。案件的首要争论点是这些构成元素是否构成版权保护的对象。美国联邦上诉法院二审认可了涉案软件接口的可版权性。该裁判观点和以往业界对程序接口不受版权保护可自由使用的观点相悖。而在此案之后，关于软件接口的版权案件也开始增多，其中比较典型的如下述两个案件。

“Synopsys， Inc. v. Atoptech， Inc.”案[12]中，Atop？ tech公司编制的应用程序利用了Synopsys软件所使用的相同输入和输出格式，以实现软件之间的“互操作性”，进而降低潜在客户可能会面临的软件转换成本。经过审理，法院支持了Synopsys公司的版权主张，对接口给予了版权保护。“Cisco Sys. v. Arista Net？ works， Inc.”案[13]则是与“互操作性”有关的另一个涉及接口的案例。Cisco公司认为，Arista逐字复制使用了思科的命令行用户接口（CLI）程序，包括500条多行命令，来配置Arista的以太网交换技术，对此Arista公司予以承认。争论的焦点是复制的内容是否能够得到版权保护。Arista在一审法院胜诉。法院认为，Arista受到“功能性和既存网络行业协议的约束”，其复制CLIs的行为应该被允许，也就是说，法院认为，基于消费者高度熟悉并使用Cisco公司的CLI（与其他CLI相比），Cisco公司的CLIs已成为创建Arista软件的必要元素。法院经审理，Cisco公司的CLI及相关命令已成为业界标准。Cisco公司提出上诉称，这些命令行接口并不是基于Cisco公司创建时的行业标准；而是在Arista复制它时，它成为行业标准。Cisco公司强调指出，“公平原则”只否认对创作时（而不是复制时）常见的汇编的保护；此外，消费者熟悉度和可用性的模糊概念不足以证明Cisco公司命令行接口对Arista软件的创建是“必要”的。在法院作出裁决前，双方于2018年8月达成和解。该案虽未进行到最后法院的裁决阶段，争讼各方基于各自的利益考量进行了和解，但可以预见，无论何方胜诉，都将给软件接口的版权保护争议添加新的不确定性因素，甚至影响相关产业政策的变化。

这些案件都涉及到之前普遍认同的基于“互操作性”不对编程接口进行版权保护的问题，都产生了新的争议。在案情上，往往是市场领导者试图利用编程接口的版权保护，对竞争对手提起诉讼，以阻止竞争对手进入市场或者制造障碍，提升对手竞争成本。而如果他们的这种版权主张获得了支持，这将使美国程序员在竞争中处于不利地位，而其他司法管辖区（如欧盟）的开发人员认为，版权并不保护互操作性所必需的程序元素[14]。因此，由“甲骨文诉谷歌版权”案引发的第二场关于应用程序编程接口版权保护的战争还在继续，但似乎已接近尾声，且与第一次“战争”的结果不同。雖然，最终的结果还取决于美国最高法院是否同意审理本案，以及如果审理本案后，最终的裁决结果如何，但目前的状况，二审法院对编程接口进行版权保护的裁决已经对软件行业的运行生态产生巨大的冲击。

三、“合并”规则和“功能性”视角下接口可版权性的否定

甲骨文公司和谷歌公司具有强大的行业影响力，而Java作为最受欢迎的编程语言的现实③与利用Java资源编写的软件接口的普遍性，以甲骨文诉谷歌的应用程序编程接口（API）的版权问题为切入，对接口的可版权性进行深入分析，具有代表性并能反映软件行业关于程序接口的可版权性问题的共性。

甲骨文公司于2010年基于收购升阳（Sun）公司获得了Java的所有权。该Java平台能够用于编写和运行Java程序软件，可以使程序员不必为了在不同的计算机硬件上运行而不得不为此而重新编写程序，也就是说，利用Java实现“一次编写，普遍运行”的目标[15]。Java平台的Java SE包括Java虚拟机和Java应用程序编程接口（API）及其他。Java API是用于常见和更高级计算机功能的“预写Java源代码程序”的集合，通过Java API“允许程序员使用预先编写的代码将某些功能构建到自己的程序中，而不是从头开始编写自己的代码以执行那些功能。”预先编写的程序被分类为“包（Package）、类（Category）和方法（Meth？ od）”。具体来说，API包（Package）是类（Category）的集合，每个类（Category）又包含方法（Method）。为了在程序中包含特定功能，程序员需要调用Java“声明代码”。声明代码是一行或多行源代码，它“声明或定义”（i）方法名称和（ii）“输入”和方法带来的预期，以及“输出”。在声明代码之后，每种方法都包括“实现代码”，该代码接受输入并向计算机提供分步指示，以执行声明的功能。

本案涉及的主要事实是谷歌公司在自己开发的Android手机平台中使用了来自Java SE 1.4版本和5.0版本的37个API软件包，并且复制了其中“声明代码（Declaration Code）”和“结构、次序和组织”（Struc？ ture， Sequence and Organization， SSO），对此，诉讼双方均予以认可。本案涉及主要争论点是API软件包是否构成版权保护的作品，如果构成版权保护的对象，谷歌公司对本案涉及的使用行为，是否构成版权法上的合理使用。主要争论点或者说根本争论点为应用程序编程接口（API）是否具有可版权性。

（一）“合并”规则审视下接口可版权性的否定

独创性是作品可版权性的同义词，可以说，判断作品的可版权性是独创性分析的基本功能[16]。因此，对涉案API的可版权性分析的逻辑起点，就是对其独创性进行分析。2008年，Java API有166个“程序包（package）”，分为600多个“类（classes）”，6 000多个“方法（method）”。这可以简单理解为，Java API有166个“文件夹”（程序包），所有这些程序包含600多个预编写的程序（类），以执行总共6 000多个方法（method）。对于这些程序包，谷歌对甲骨文公司主张的独创性是予以认可的。从技术结构上，可以将API比作图书馆，API“包（package）”就像图书馆里的书架，“类别（class）”就像书架上的一本书，而“方法（method）”则像书里面的一个“如何做”的章节。本案涉及的是37个API包的文字元素，即声明代码（Dec？ laration Code））和非文字元素，即序列、结构和组织（Sequence， Structure and Organization， SSO）。“方式”和“类别”是被用来执行某种需要的功能，而“声明代码”就是用来描述“方式”和“类别”的“头文件（head？ er）”，并且为实现规定的功能，“宣告代码”必须要保持一致，具有固定的含义[17]。谷歌公司复制了涉案37个Java API“声明代码”，但自己编写了“执行代码（Implementing Code）”。甲骨文公司认为，该“声明代码”表明了每个API包的结构，就像文章中的章节标题和主题句；当谷歌公司复制了“声明代码”，也就复制了甲骨文公司的API包的“序列和组织”；也就是说，谷歌复制了“声明代码”，然后通过转述其余的“结构、序列和组织（SSO）”，进行了自己的“执行代码”（Implementing Code）的编写。据此，甲骨文公司认为，谷歌公司进行了整个“结构、序列和组织（SSO）”的非文字性复制。因此，在涉案API具有独创性的前提下，可版权性就要受制于其“声明代码”是“思想”还是“表达”的判断。

“声明代码”由具体的名称和短语构成。但版权法不保护名称、标题或简短短语或表达方式[18]；即使名称、标题或短语是新颖的或与众不同的，也不能受版权保护。一审法院对此予以认可，但二审法院认为，保护与否的关键在于“这些短语被使用或者组织在一起的方式是否展示出创新性”，而甲骨文公司“在创造API包，编写相关的声明代码时，在‘方法的‘声明的选择和组织过程中展示了创新性”[19]。据此认定了Java API的可版权性。

笔者认为，二审法院的观点看似合理，但仔细观之，根据Java的编程规则，对于实现相同功能的“方法（method）”而言，对于该“方法”所进行的“声明（decla？ ration）”应当一致，据以实现相同的功能。即作品虽具有独创性，但还要经过版权法其他原则如“合并”规则、“功能性”排除规则等的检验。因此，Java API包编写声明代码的方式就是唯一的。谷歌为了实现“方法”的功能，所编写的“声明”代码，应当与甲骨文公司的API的一致。基于Java语言开放的Android系统，虽然谷歌对自己基于Java语言编写的Android操作系统又自己编写了其他的执行代码，以实现达到相同的功能，有了其他不复制亦可以实现该功能的方法，但不能反向推论得出谷歌对前述“声明代码”的就不能进行复制的结论。

就Java语言自身而言，有自己的语言要素和语法结构。在“方法（method）”之后更高一级别为“类（class）”类。一个类通常包括保存“值（value）”的字段和对这些“值（value）”进行操作的“方法”。类是Ja？ va语言中的基本结构元素。Java程序被编写为一个或多个类。一个类中可以有多个方法，而一个包中可以有多个类。Java程序中的所有代码都必须放在一个类中。而“声明（declaration）”是一行包含“类”的名称和其他定义“类”类的信息的代码。“声明”的这种作用也要求其尽量简洁，并且基于实现相同的“类别”和“方法”，其表达极其有限。

在这种“声明代码（Declaration Code）”表达有限的情况下，二审法院认为，谷歌公司为实现相同功能，具有多种不同于甲骨文公司进行的编写方式，排除了版权法“合并”规则的适用。当表现一定思想的表达有限时，如果仍然对表达进行保护，则难免限制公众的思想，这些表达也被视为“思想”而不受保护[20]。该规则是版权不保护思想这一基本原则的逻辑扩展，即当对某思想的表达方式有限情况下，如果对这种有限的表达进行版权保护，则有碍思想的传播，甚至形成了版权保护思想的事实。这是与版权法的立法目的和基本原理相悖的。该规则对表达方式的多寡并无具体的数量要求，但一般情况下方式数量自然不能多，但根本上还应当考虑对思想、功能的具体表达方式的优劣或效率。如虽然存在其他表达方式，但这種表达方式的效率较低或者社会成本较高，应也不能以其存在其他表达方式，而据以排除“合并”原则的适用。因此，二审法院因此作为“存在其他方式”作为排除使用该规则的理由，难以令人信服。由此导致的结果将是整个软件行业编程成本的增加，效率的降低。

此外，就软件本身的技术特性而言，软件编写不同于一般作品，如文字作品的创作，往往需要体现一定的遣词造句，讲究一定的文学素养等，软件是一连串冰冷的代码构成，而这些代码的最终编写的目的是要实现一定的功能。基于此，对于软件语言和一般语言的标准就应有所不同。在一般文学作品中所体现的字或者词，在编程语言中，就是具体的单个代码或者较短的词组。但申而言之，软件行业存在明显的网络效应。网络效应的形成和最终结果如何，很大程度上会取决于整个软件编写的生态，有赖于行业内部共通的“语言”和“语言”的效率。为实现这种效率，并考虑编程代码要实现的功能价值，对于编程语言“字”、“词”、“短语”的理解就应进一步扩展，甚至包括“句”，以实现软件编写语言利用的高效和软件之间的互通。而且从整个Java语言体系和产品体系的角度去看，“声明代码”的基础性作用，体现了更多的功能属性，难以作为具有独创性的表达。综合而言，“声明代码”本身仍然属于不受著作权保护的基本语言要素，在此基础之上才有独创性表达的探讨空间，进而为软件行业留足“公共领域”，便利软件的编写和互通。正是“独创性”理论和“公共领域”概念工具在版权法机制内的有机配合，实现了良性版权机制的至深关切和终极目标[21]。

（二）接口“表达”功能性视角下可版权性的否定

“思想”和“表达”之间的关键区别很难得出，划清界限的指导性考虑因素是保持竞争与保护之间的平衡[22]。既要考虑对创作者的保护，以便对其形成激励，还要注意这种保护不能形成对社会创新的阻碍，进而降低社会竞争的可能。具体到涉应用程序编程接口案件，突出的问题是，如何为了实现“互操作性”，如何确定“思想”和“表达”的界限，并进而确定应用程序编程接口的是否具有可版权性。

谷歌公司主张使用Java API开发Android智能手机操作系统，其目的乃是“为了使广大程序员采用熟悉的语言编写程序，并有利于软件行业的互操作性”。因该接口具有互操作性功能，属于美国版权法第102（b）条规定的情形，排除其版权保护。美国版权法第102（b）条规定，任何情形下，都不得将对原创作品的版权保护延及至思想、程序、过程、系统、操作方法、概念、原理、发现，不论这些内容在作品中以何种形式阐述、说明、解释或体现。美国国会报告强调，第102（b）节“绝不会扩大或缩小版权保护的范围”，并且“其目的是重申……表达与构想之间的基本二分法不变。第102（b）条不会仅仅因为某种表达体现在一种操作方法中就排除了对该思想特定表达的保护。”在评估版权性时，地区法院必须找出作品的表达，然后将可保护的表达与“不可保护的思想，事实、过程和操作方法”分开。最终一审法院美国加州北区地方法院认可“声明”和“结构、序列和组织”的“互操作性”功能性特征，并基于版权不保护思想而认定涉案接口不能获得版权法的保护。

软件之间的“互操作性”是软件之间实现互联互通及信息交流的基本保障。对于这种互操作性是不是必须限于使用接口代码后要实现对之前软件的互操作，还是说可以通过此“声明代码”进行新的创作，以实现对新的产品之间的“互操作”，则并无明确规定；而法院对此该“互操作性”是否是第102（b）中“功能”的理解，一定程度上决定了涉案API是否能够得到版权保护。而本案中，联邦上诉巡回法院基于An？ droid系统不能对Java平台反向兼容，并不认可谷歌公司关于“互操作性”功能的主张，进而认定此因素应是在对Java API版权保护后，针对谷歌公司对涉案API使用行为进行合理使用判断的考虑因素。此推论并不能让人信服，版权保护的对象判定是一个基于作品的本质判断问题，应具有本体性问题，不应受外界因素的影响而发生改变。而以上述逻辑，如谷歌公司反向兼容了Java平台，则按照上诉逻辑，应导致基于思想表达二分原则，因软件接口因为“互操作性”功能而不受版权法保护，则明显是由外界因素决定了作品是否具有可版权性的本体性问题。这是以事实判断来代替了法律判断。

对于软件接口的功能性认定，仍然应从版权保护作品的本质规定性去寻找，这种结果也不应由于外界因素的变化而发生改变。在此需要注意的是，此处的功能性并不是作品具有的作用或效能，即不是其可能具有的美学效能或者物理功用，这是事实功能性，这种功能性与法律是否保护的功能性是不同性质的问题，仅有法律功能性才是版权法功能性原则的内容，是版权法所不保护的“技术”方案，这强调的是其狭义上的“技术”含义，即技术是指制造某一产品的系统知识，可将其等同于专利法上的“技术方案”。该案“声明代码”即使具有替代性，谷歌公司可以其他方式加以实现其功能，但“替代设计的可获得性并不完全表明其不具有功能性”[23]。

本案裁决关于否定谷歌基于“互操作性”功能而不认可认定涉案API的具有的功能性观点，对整个软件行业创新造成负面影响。因为功能性原则，对于具有一定使用功能的作品，如实用艺术作品、计算机软件等版权保护目的的实现上，是促进创新，降低垄断的有效途径。对于该问题的判断，更要从版权法立法目的出发，基于产业政策导向，做出最后的判断。

四、鼓励创新和反垄断视角下接口可版权性的否定

如上分析，对于应用程序编程接口是否受版权保护，从版权法律角度进行分析已可以得出结论。基于应用程序编程接口在软件之间实现互操作的重要作用，对其尝试从更宽视野去分析，应有助于我们做出并进一步验证是否对其进行版权保护的判断，以实现版权法所要保护的促进科学、文学的发展与繁荣的目标实现。

（一）促进创新视角下可版权性的否定

软件行业是网络效应得以显现的重要领域之一，软件本身由于更多人使用，软件用户更易与其他用户进行信息交流互通[24]，这点在即时通讯软件体现上更为明显。为了实现软件之间的协作开发和具有互操作性，软件开发人员必须将自己的應用程序代码连接到其他开发人员编写的代码，这些就是有应用程序编程接口来实现。某种意义上说，共享的应用程序编程接口是现在已建立的行业机制，可以在促进创新的同时保护每个开发人员的创造性作品。没有共享的接口，每个设备和程序都是一个孤岛，现代软件开发根本不可能发生。而应用程序编程接口更是实现这种互通的桥梁，通过软件接口实现的互操作性允许独立开发人员在他人的工作基础上进行开发，节约了开发时间，并且使软件互联，推动实现网络效应，真正的实现网络互联。可以说，互操作性是已经定义了现代技术发展的特征，并且随着物联网在未来几年的发展而变的更加重要。软件接口作为重要且高度创新的软件行业的重要组成部分，是实现互操作性的关键，对程序接口的控制将对软件创新和网络发展的未来产生根本影响。对于软件开发人员来说，继续从事创建高度协作和可互操作的软件系统的能力和最终结果，将一定程度上取决于应用程序编程接口在法律上如何进行界定。

软件接口对创新来说是必要的④，而关于为保障软件的互操作性及实现软件行业的创新，美国软件开发者联盟（Developers Alliance）向美国最高法院提交了法庭之友意见，请求美国最高法院审理此案，并认为联邦上诉巡回法院的裁决在一定程度上颠覆了以往的应用程序编程接口不受版权保护的共识，造成认知上的混乱，现寄希望于通过最高法院的审理以“提供必要的法律上的明确性”⑤。

版权法的激励创新，一方面是通过给予创作者版权实现对创作者的激励，另一方面则是通过著作权的限制制度，以便作品使用者使用作品，降低使用成本和效率，以促进更多的创新。给予软件接口在软件行业中的特殊作用，对其不予进行版权保护，这是实现版权立法保护促进创新作用根本目的应有之义。

（二）反垄断视角下接口可版权性的否定

版权法的立法目的是促进科学和文化的繁荣，而关于版权法的争议解决要服务于版权法的立法目的，对应用程序编程接口争议的解决方案要能够反映其促进创新、竞争和消费者福利的最终目标。甲骨文作为Java平台的权利人，拥有Java语言及相关产品，虽然Java语言免费使用，但因语言而成就的产品是不是就像一般的版权作品一样符合版权法的基本保护门槛就要受到保护，并没有简单的答案。尤其是涉及到软件这样一个本身具有一定技术功能的作品，情况更显复杂。加之基于Java语言的最大市场占有量，决定了与其相关的Java产品具有软件市场的绝对影响力，就应用程序编程接口而言，如联邦上诉法院的裁决，即便是像谷歌这样的大公司也必须支付巨额的软件接口许可使用费，更遑论一般的软件企业，也会因使用带来较大的成本。即使这种使用行为有可能构成合理使用，但囿于具体使用情形的不同，法律判断的差异，是否能够构成合理使用具有不确定性，这必然会影响许多软件企业未来的发展，甚至一些本有可能对现有软件企业造成挑战的初创企业也会因为联邦巡回上诉法院对软件接口的过度保护而造成壁垒，丧失挑战的机会和成功的可能。

相对于一般作品的版权保护，软件接口的版权保护尤其具有反竞争性，基于主流平台的巨大的网络效应，这种保护往往会阻止新进入者的挑战，巩固基于软件的垄断，减缓软件市场的创新和竞争⑥。因此，基于自由竞争的鼓励和垄断的限制，对应用程序编程接口不进行版权保护也就成了当然之义。

结语

对于应用程序编程接口能否得到版权保护，从“甲骨文诉谷歌版权”案引发的观点撕裂并不会因为联邦上诉巡回法院的裁决结果而戛然而止。从单纯版权法律角度来看，联邦上诉巡回法院的裁决，已经打开了对软件接口进行版权保护的潘多拉盒子，这点从类似争议的出现及对以往行业认知颠覆后的争执不休，都可以佐证；而从保护创新，增添市场活力的角度，对应用程序编程接口的版权保护更是与此目标相背离；基于接口的互操作性功能及对其在软件编写中的基础性作用，对接口的版权保护更易使相关“权利人”形成一定的市场垄断地位，进而损害竞争，阻礙创新，这点也是不符合版权法的立法目的。

虽然美国最高法院已决定审理“甲骨文诉谷歌”案，但在该案的二审裁决并未被推翻之前，该裁决依然要得到执行，此时，根据该裁决而进行必要的行业调整也是客观需要；如果二审法院的裁决并没有得到美国最高法院的改变，则可以预见关于应用接口的版权诉讼会有一个上升的态势，随着行业规则调整的形成，会趋于新的动态平衡。初期，应用程序编写人员的应用开发成本会因为软件接口版权保护而有所提升，其具体编写行为也会涉及更多法律判断的不确定性，例如是否合理使用。但长期来看，某种新的或者旧的编程语言“语法体系”带来的彻底开放的软件接口的出现，进而形成新的市场格局及规则变化，也并非没有可能。对软件开发企业而言，短期内从微观层面看，基于司法裁决结果，进行法律风险的规避，做好软件开发及应用的合法合规，尤其避免版权侵权风险是首要目标；宏观层面，要基于该风险进行开源软件的选择，以规避侵权风险；长期观之，软件开发底层能力，包括编程语言及其他构成要素的设计开发能力，才是软件行业未来真正的核心竞争力，这于我国软件行业亦是如此，甚至是当务之急，更是未来方向。

参考文献：

[1] Google v. Oracle： Silicon Valley Braces for "Lawsuit of the Decade" as Google Petitions for Cert to decide API Copy？ rightability[OL]. [2020-05-18]. https：//jolt. law. harvard. edu/digest/google-v-oracle-silicon-valley-braces-forlawsuit-of-the-decade-as-google-petitions-for-cert-todecide-api-copyrightability.

[2]谷歌vs甲骨文史诗级版权诉讼案！甲骨文抄袭黑历史被翻出，10年API之争下周开审-电子头条-EEWORLD电子工程世界[OL]. [2020-05-18]. http：//news.eeworld.com. cn/mp/leiphone/a85200.jspx.

[3] 2019年全球及中国软件行业市场现状与竞争格局分析[OL]. [2020-05-18]. http：//tradeinservices.mofcom.gov.cn/ article/lingyu/rjckou/201908/88392.html.

[4]§3：72.The 1976 Copyright Act， Patry on Copyright.

[5] Menell P S. Rise of the API Copyright Dead： An Updated Epitaph for Copyright Protection of Network and Function？ al Features of Computer Software[J]. Harv. JL & Tech.， 2017， 31：305-473.

[6] Apple Computer， Inc. v. Franklin Computer Corp.， 714 F.2d 1240， 1253， 1983 U.S. App. LEXIS 24388， *41， 219 U.S.P.Q. （BNA） 113， 124， Copy. L. Rep. （CCH） P25，565， 70 A.L.R. Fed. 153.

[7] Whelan Assocs. v. Jaslow Dental Lab.， Inc.， 797 F.2d 1222.

[8] Computer Associates International， Inc. v. Altai， Inc.， 982 F.2d 693.

[9] Lotus Dev. Corp. v. Borland Intl， Inc.， 516 U.S. 233.

[10] Sega Enterprises Ltd. v. Accolade， Inc.， 977 F.2d 1510.

[11] Samuelson P. Functionality and Expression in Computer Programs： Refining the Tests for Software Copyright In？ fringement[J]. Berkeley Tech. LJ， 2016：1215-1300.

[12] Synopsys， Inc. v. Atoptech， Inc.， 2013 U.S. Dist. LEXIS 153089， 2013 Copy. L. Rep. （CCH） P30，507， 2013 WL 5770542.

[13] Cisco Sys. v. Arista Networks， Inc.， 2015 U.S. Dist. LEX？ IS 136444.

[14] Band J. The Global API Copyright Conflict[J]. Harvard Journal of Law & Technology （Harvard JOLT）， 2017（31）： 615-637.

[15]How Will Java Technology Change My Life？ （The Java？ Tutorials > Getting Started > The Java Technology Phe？ nomenon）[OL]. [2020-05-18]. https：//docs.oracle.com/ja？ vase/tutorial/getStarted/intro/changemylife.html.

[16]王坤.論作品的独创性——以对作品概念的科学建构为分析起点[J].知识产权，2014（4）：15-22.

[17] Oracle Am.， Inc. v. Google Inc.， 872 F. Supp. 2d 974.

[18] 37 CFR 202.1（a）.

[19] Oracle Am.， Inc. v. Google， Inc.， 750 F.3d 1339.

[20]王迁.知识产权法[M].第6版.北京：中国人民大学出版社， 2019：54.

[21]黄汇.版权法“独创性”理论的困境与出路[J].电子知识产权，2009（9）：84-87.

[22]Herbert Rosenthal Jewelry Corp. v. Kalpakian， 446 F.2d 738.

[23]梁志文.论版权法上的功能性原则[J].法学，2019（7）： 150-162.

[24]李晓华.网络效应、反盗版及其对我国软件产业发展的启示[J].中国社会科学院研究生院学报，2007（1）： 46-51.

The Negation of "Copyrightability" of Application Programming Interfaces

——Taking Oracle v. Google Application Programming Interface Copyright Controversy as an Example

JIA Lei

（Institute of Intellectual Property， Zhongnan University of Economics and Law， Wuhan 430073，China； Insti？ tute of Intellectual Property， Henan University of Economics and Law， Zhengzhou 450046，China）

Abstract： Application programming interfaces （API） are critical to the interoperability of software and operating sys？ tems， which play an important role in the software industry. The question of whether an interface is copyrightable has gone through a transition from dispute to consensus and then to the overthrow of consensus in the United States. The copyrightability of the API involves fundamental issues in the scope of software protection. Whether to apply the "merg？ er" rules of copyright law or consider its own "interoperability" functions， and consider the needs of innovation and ef？ fective competition in the software industry， the copyrightability of API should be excluded.

Key words： interface； merge； interoperability； functionality； copyrightablity

基金項目：高等学校学科创新引智计划（111计划）资助（B18058）；中南财经政法大学一流学科建设高校建设方案拔尖创新人才培养项目资助

作者简介：贾磊（1979—），男，河南周口人，中南财经政法大学知识产权学院博士研究生，河南财经政法大学知识产权学院讲师，研究方向：知识产权法。

①对于应用程序编程接口，审理法院指出，具体名称并不重要，关键是具体的内容是什么，本案中应用程序编程接口指的就是相应程序的源代码。程序“接口”并不同于日常生活中不同物品相互连接所需的物理接口，其往往表现为具体的应用程序编程代码，其功能的实现一般是利用一定编程语言，并根据其语法，通过具体的函数、变量等通过程序编写来实现。应用程序编程接口之争，最直观的落脚点还是应用程序代码表达的权利之争。See Oracle Am.， Inc. v. Google Inc.， 750 F.3d 1339。

②互操作性指（Interoperability）是指产品或系统的接口能够被其他产品或系统理解，并可以无限制地与之共同发挥作用。互操作性实现了应用之间、应用与操作系统之间互联互通，使其发挥各自功能并促进网络效应的形成。See http：//interop‐erability-definition.info/en/。

③TIOBE是一家专门从事评估和跟踪软件质量的公司，发布TIOBE编程社区索引以反映编程语言受欢迎程度的指标。该索引每月更新一次。2019年11月Java编程语言仍位列第一。See TIOBE Index | TIOBE - The Software Quality Company[OL]. https：//www.tiobe.com/tiobe-index/，最后访问时间：2019年11月19日。

④基于软件接口对软件创新的重要作用，为支持谷歌公司向美国最高法院提交的审理该案请求，78名计算机领域的科学家提出了法庭之友意见。See Motion For Leave To File Brief Of 78 amici Curiae And Brief Of 78 Amici Curiae Computer Scien‐tists In Support Of Petitioner。

⑤美国软件开发者联盟为支持谷歌公司的再审申请，向美国最高法院提出了法庭之友意见，以表达该案关于软件接口的问题对软件版权保护的竞争意义。See Amicus Curiae Brief Of Developers alliance In Support Of Petitioner。

⑥美国反垄断协会（“AAI”）是一个独立的非营利组织，致力于促进保护消费者、企业和社会的竞争。通过研究、教育和宣传竞争的好处以及将反垄断执法作为国家和国际竞争政策的重要组成部分来为公众服务。该协会向美国最高法院提出法庭之友意见，以请求最高法院审理甲骨文诉谷歌版权案。See Brief For The American Antitrust Institute As Amicus Curiae In Support Of Petitioner。