北京,中国

热点观察 | API是否受版权保护——谷歌、甲骨文Java API侵权案观察

2019年11月15日,历经辗转,谷歌终于叩开了美国联邦最高法院的大门,将它与甲骨文延续了近十年的恩怨呈到了大法官们的案前。原本众人期待在本个开庭期结束前(2020年6月)能获知这场终极之战的结果,未曾想因席卷全球的新冠病毒,最高法院临时休庭,本案原定于3月24日的庭审也随之推迟。

本案主要涉及两个争议焦点:(1)软件接口是否能获得版权保护;(2)谷歌为开发安卓系统而使用软件接口,是否构成合理使用?这也对应着谷歌为了阻挡88亿美元的天价赔偿而设立的两道防线。目前双方均已提交意见,各自的后援团也递交了洋洋洒洒几十篇法庭之友意见书。[1]大法官们会被哪一方说服,谷歌能守住哪一道防线,最终会形成9:0的一致判决还是5:4的险胜,还无法预知。

合理使用抗辩更依赖于个案判断,而对于软件行业而言,“API是否受版权保护”无疑更具有讨论意义。尽管在读完双方意见书后,本文依然未能结束摇摆,但期待能为读者们提供了解本案的小小窗口。


1.前情提要——两大科技巨头的十年恩怨
2010年1月,甲骨文正式完成对Sun的收购,获得了Java的所有权。同年8月,甲骨文起诉谷歌未经许可在安卓系统中使用37个Java API包(包括java.io,java.lang,java.sql, java.text等),侵犯了7 件与 Java 相关的专利和版权。[2]当时大概谁也没有想到,这场战事绵延近十年。而这十年间,谷歌携安卓系统攻城略地,迅速成为移动端操作系统的王者。
2011至2012年间,双方尝试进行了多次和解谈判,终因未能达成一致,重回法庭。
该案在地方法院和联邦巡回上诉法院之间辗转了两次。[3]

 

第一次审理

第一次审理时,陪审团认定谷歌侵犯了甲骨文Java SE库的版权,但在谷歌是否构成合理使用的问题上陷入僵局。

2012年5月,加州北区联邦地方法院判定Java API不受版权保护,“如果只有一种写作方式,那么基于合并原则(merger doctrine),此种表达不能获得版权保护。”[4]10月,甲骨文上诉至联邦巡回上诉法院。[5]

2014年5月,联邦巡回上诉法院认定Java API受版权保护,“没有人阻止谷歌编写其自己的声明代码,与其实现代码一起,完成与Java SE库相同的事情。”[6]同年10月,谷歌申请美国联邦最高法院听审此案。

2015年6月,联邦最高法院拒绝了谷歌的调卷令申请。

 

第二次审理

根据联邦巡回上诉法院的指令,案件重返加州北区法院,由该院审理谷歌另外提出的“合理使用”主张。

2016年5月,陪审团认定谷歌的行为构成合理使用。10月,甲骨文再次上诉至联邦巡回上诉法院;11月,谷歌也提起了上诉。
2018年3月,联邦巡回上诉法院推翻了陪审团的认定,再次支持甲骨文,认定谷歌侵权。
2019年1月,谷歌向联邦最高法院上诉。2月,包括微软、Mozilla、开发者联盟、Python软件基金会在内的谷歌盟友们陆续向联邦最高法院递交了法庭之友意见书,其中一份由78位计算机科学家联合签署的意见书打动了大法官们,该院终于同意复审本案。

 

2.引起战火的Java API到底是什么

 

Java编程语言具有“一次编写,到处运行”(write once, run anywhere)的跨平台特性,被广泛应用于企业级Web应用开发和移动应用开发。Java SE(Java 2 Standard Edition Platform)是甲骨文为用户提供的程序开发环境标准版,提供了开发与运行Java软件的编译器等开发工具、软件库及Java虚拟机。谷歌被诉抄袭的37个Java API包(共计11,300行声明代码)就来自于Java SE的JDK(软件开发工具包)。[7]。

API是Application Programming Interface的简称,可译为“应用程序接口”。API 的一个主要功能是提供通用功能集。程序员使用API调用开发平台预先封装好的程序,从而无需访问源码或理解内部工作机制的细节,也可以避免编写通用功能的程序。作为一种有效的代码封装模式,API开发模式最早由微软Windows采用,后为许多商业应用开发的公司所借鉴,并开发出某些商业应用系统的API函数予以发布,方便第三方进行功能扩展。[8]

前述预先封装好的、便于程序员调用的程序,在Java中被称为method(方法)。method被分类到不同的class(类)中,class又被打包入不同的package(包)中。API即为供程序员调用method的接口。API由声明代码进行定义,声明代码中包含访问权限(私有或公有)、返回类型、名称及参数。使用Java API时,须包含完整路径且必须符合声明代码的定义,格式为“java.package.class.method”。举例而言,下图展示了名为“java.lang.Math.max”的API,其对应的方法“max”用于筛选两个整数(x和y)中的较大值,该方法位于包lang下的Math类中,第1-3行为该API的声明代码,而4-6行则为实现代码。[9]

此处的实现代码十分简单,但在实践中,虽然执行的是完全相同的功能,但不同的程序员写出的实现代码可谓千姿百态,有时也可能千奇百怪。

谷歌被诉抄袭的,正是API的声明代码及其组织结构(即方法、类和包三层次的组合方式,以下将其称为API布局)。[10]

在抽象的概念面前,双方都各尽所能地通过类比的方式,试图“引导”法院感性理解API是什么。谷歌自然要突出API的功能性特征,甲骨文则尽力展示API及其布局具有独创性。

谷歌指出,软件接口在计算机程序和平台之间传递信息和指令,可类比为电源插座、汽车方向盘和QWERTY键盘,当然是要按照相同的模样制造。[11] API的布局则类似文件系统,“包”就像是文件柜,“类”如抽屉,“方法”则是抽屉中的文件夹,至于“声明”,是用于标识每个文件柜、抽屉或文件夹的标签。[12]

甲骨文自然是不赞同所谓“文件柜”的说法。在甲骨文看来,API及其布局都是经过Java架构师们精挑细选的,对于Java SE而言是精髓、骨架。声明代码更像是书中的散文,具有独创性;而正如版权法保护情节、人物及具有独创性的原有材料的汇编,版权法也保护计算机程序的组织结构。[13]

 

3.本案的争议焦点

美国联邦最高法院将就如下两个问题进行审理:软件接口是否能获得版权法保护;谷歌为编写新的计算机程序而使用软件接口,是否构成合理使用?本文讨论聚焦于前者。

 

谷歌的申请意见

谷歌于今年1月6日递交了意见书,随后又于3月11日针对甲骨文的答辩状提交了补充意见书。在其意见书中,谷歌力图说服法院API不应受版权保护,[14]]且为法院提供了两种路径:一种是判定API属于“操作方法”(method of operation),相应地,整个Java SE库的组织结构都属于纯功能性的,不应受保护;另一种,则是基于合并原则,认定重用API属于有限表达,不应予以保护。[15]从篇幅上看,谷歌显然把希望更多地寄托在了合并原则上。
谷歌指出,在安卓中使用Java SE库的声明代码,是一种“重新实现”(reimplementation)的行为,即编写新软件来执行旧产品某些功能的过程。通过重新实现,开发者创建了自己的代码来执行特定的功能,只不过是重用了旧产品中已为用户所熟知的、数量有限的指令。[16]
谷歌虽然重用(reuse)了Java SE库中的声明代码,但方法的实现代码是自己写的。软件行业长期以来的实践,都是允许重用软件接口的。而谷歌之所以这么做,完全是因为别无他法。Java程序员们已经十分熟悉这些声明,并且使用这些声明对应的API编写程序,所以谷歌必须使用Java API的声明代码,才能够正确识别、响应程序员们所编写的调用
事实上,谷歌也承认,自己完全有能力编写一套全新的声明代码,但那意味着程序员们必须投入时间来学习和熟悉这一套新的指令。因此,使用Java API的声明代码,成为谷歌的唯一选择,属于“有限表达”。

 

甲骨文的答辩意见

在这份2月递交的答辩状中,甲骨文似乎难掩激动,开篇第一段即指出:“谷歌很有问题!明明实施了令人震惊的剽窃行为,现在又妄想改写版权法来合理化其行为。这不可以!” [17]
就谷歌提出的有限表达抗辩,甲骨文反驳道:
Java SE作者完全可以将所有的30,000个方法打包进一个类里,电脑运行起来也不会有什么问题。他们没有那么做,是因为对于用户来说太不友好。所以,作者们利用他们的智慧对这些方法、类和包进行了布局。如何将方法分组到类,如何将类分组到包,程序之间的关系如何以及编译时的相互依赖,完全出自Java SE作者富有创造性的选择。[18]
在这成千上万的选择中,并没有人阻止谷歌去编写它自己的声明代码。然而,谷歌为了加速推出安卓,逐字抄袭了37个Java包中的11,330行代码。这11,330行声明代码对于Java SE而言,是如此的核心和重要,以至于谷歌抄袭的比例大小,根本无关紧要
。[19]

 

4.后援团大比拼

谷歌和甲骨文背后都有着声势浩大的后援团。联邦最高法院网站显示,该案被正式受理后,各方共递交78份法庭之友意见书,其中26份支持谷歌,32份支持甲骨文

当然,这并不是比拼数量的时候。谷歌获得了包括微软、IBM及Red Hat等科技企业、Python软件基金会、计算机与通信行业协会、互联网协会等非营利组织和协会,以及150多名学者和计算机专业人员的支持,似乎“科技”站在了谷歌这一边。关于这一点,甲骨文的执行副总裁Ken Glueck发布了一篇言辞颇为激烈的博文,嘲笑谷歌和它的支持者们不过是利益交易的关系,[20]也完全不能代表“科技”的声音。[21]

甲骨文最大的后援,非美国联邦政府莫属,且联邦首席律师已经获得联邦最高法院的同意,将参与庭审,代表美国政府支持甲骨文。

本文最关注的,是那份成功说服了最高法院复审本案的意见书。[22]尽管对其中部分表述有不同看法,但光是看到落款处那一长串计算机科学史上金光闪闪的名字,就肃然起敬——被誉为“C++之父”的Bjarne Stroustrup,Python语言的最初设计者和主要架构师Guido van Rossum,联合设计和实现了Unix操作系统并创造了B语言的Ken Thompson,苹果的联合创始人Steve Wozniak,互联网先驱Vinton G. Cerf……

科学家们回顾了软件发展的历史,展示了得益于API重新实现而诞生的影响深远的伟大软件:计算机制造商重新实现IBM BIOS API,从而有了DOS,并最终诞生了windows系统;苹果通过重新实现Unix API,创造了桌面端的OS X操作系统和iOS系统。即便是Java,也不是Sun公司纯粹白手起家的产物,也建立在重新实现其他编程语言API的基础之上(例如C语言math API、Perl语言的正则表达式API等)。[23]科学家们进一步指出:谷歌所做的,是一种长期存在且广泛普及的实践方式,其对于实现计算的基本进步至关重要,并且已经在过去数十年间推动了整个软件行业的历史创新。联邦巡回上诉法院的判决将颠覆计算机行业数十年来的既定期望,并打击该领域的持续创新。[24]

 

5.维权的破局者,还是行业规则的破坏者

 

在行业内普遍采用API重新实现开发新软件的大背景下,甲骨文史无前例地要求保护API,震惊业界。然而,其究竟是打破API维权僵局的先锋,还是破坏计算机行业沿用几十年之惯例的破坏者呢?甲骨文对于Java API主张版权,是否真的“危害了使整个计算机行业持续发展的、无与伦比的创新和竞争”?[25]

那些过去几十年间不断上演的鲜活案例,或许比法律条文本身的交锋更能打动人。但是,如果不经授权即重新实现API只是计算机行业发展过程中的一种惯性,实质上并非最有利于行业创新和发展的方式呢?正如代码开源常常被认为更有利于代码的完善,但是各国不还是选择了保护计算机程序么?

事实上,API究竟应否受版权保护,本身取决于立法者。如果必然导致垄断,阻止新的市场竞争者进入,阻碍创新,立法当然可以选择不保护API。然而,阻碍创新这个前提真的存在吗?尽管双方在此问题上泼墨良多,却似乎并不完全在一个频道。谷歌及其盟友们侧重的角度是“初创企业是否可以使用大企业的API”,如果不允许,初创企业无法参与竞争;[26]而甲骨文的角度则是“万一大企业滥用初创企业的API”,那么初创企业永远做不起来。[27]

甲骨文及其盟友坚定地认为,API应否受保护是一个不需要讨论的问题,这并非是法律盲区,现行版权法明确保护了API。声明代码属于计算机程序,版权法保护计算机程序,自然也保护API及其布局。甲骨文认为很多人过度解读了联邦巡回上诉法院的判决,该判决只是认定了谷歌的使用不合理,但是并不意味着所有人都完全不能使用Java API。[28]谷歌蓄意渲染了本案意义非凡的假象,可本案的本质不过是权利人在声讨一个抄袭者而已。

无论如何,美国联邦最高法院将通过本案厘清API在版权法上的定位。但最终的判决结果,或许只能暂时终止甲骨文和谷歌之间的硝烟。如果法院裁定API应获得版权保护,进而选择了合理使用这条路,就意味着未来的案件中,法院不得不尝试在编程语言本身和API之间寻找足够清晰的界限。而划界,比想象中要难得多。[29]

 

总之,让我们拭目以待,看这场十年大戏如何落幕!

 

[1] 本案资料大部分均可从美国联邦最高法院官网的卷宗系统中获取。

https://www.supremecourt.gov/search.aspx?filename=/docket/docketfiles/html/public/18-956.html

本文引用具体文书时将仅注明文书标题及相应页码,不再提供链接。

[2] 甲骨文的起诉书详参https://regmedia.co.uk/2010/08/13/oracle_complaint_against_google.pdf。涉诉的37个Java API包详参JOINT APPENDIX VOLUME 1,at 339-341。

[3] 各阶段诉讼的具体日期,详参JOINT APPENDIX VOLUME 1;法院判决中均会简述案件背景;多篇媒体文章也对本案诉讼历程进行了详细梳理,可参考如下文章:https://www.36kr.com/p/5294507,https://tech.ifeng.com/c/7riqNrhBeKG,

https://tech.sina.com.cn/roll/2020-03-22/doc-iimxyqwa2325421.shtml。

[4] Google, BRIEF FOR THE PETITIONER, at 10.

[5] 联邦巡回上诉法院一般不审理著作权案件,但甲骨文最初起诉时包括专利侵权,因此,本案上诉由联邦巡回上诉法院管辖。但在第一次审理时,陪审团认定不存在专利侵权,后续审理也未再涉及专利侵权问题。

[6] Google, BRIEF FOR THE PETITIONER, at 10.

[7] 甲骨文免费许可Java SE给app开发者使用,对于设备厂商或竞争平台开发者则提供三种许可方式:通过OpenJDK的免费许可(Free License,GPL协议形式放出),声明代码许可(Declaring-code license,允许使用API重新实现,但开发出的平台必须与Java SE兼容),全平台许可(Full-platform license,要求与Java SE兼容)。谷歌对前述三种许可方式都不感兴趣,曾尝试从Sun公司获得完全无限制的许可,但未能如愿,最终径自使用了Java SE的API开发完成了安卓系统。2015年底,谷歌宣布将从下一个版本的Android开始采用OpenJDK。关于Java SE许可方式,详参Oracle官网关于该问题的FAQ,https://www.oracle.com/technetwork/java/javase/overview/oracle-jdk-faqs.html

[8] 参维基百科https://zh.wikipedia.org/wiki/应用程序接口;百度百科“应用程序接口”词条。

[9] 例子来源参N.D. Cal. , Google cert petition appendix, at 224a-225a. 更准确地说,第3行是API的声明代码,而第1-2行代码主要指明API的具体位置。

[10] 双方在诉讼中实际使用的是SSO(structure, sequence and organization)来表达API的组合方式。

[11] Oracle, REPLY BRIEF FOR THE PETITIONER, at 1.

[12] Google, BRIEF FOR THE PETITIONER, at 4.

[13] Oracle, REPLY BRIEF FOR THE PETITIONER, at 21.

[14] 合并原则是美国判例法对于“思想表达二分原则”所衍生出来的法律概念,指被告所抄袭的部分虽属著作之表达,但因该著作的表达仅有一种或者只有非常有限的的方式,则就该著作所谓之“表达”与“思想”密不可分,故不受著作权法之保护。参陈和贵,《智慧財產權侵權分析與訴訟攻防實務》,2017年2月,第19页。

[15] Google, BRIEF FOR THE PETITIONER, at 19.

[16] Google, BRIEF FOR THE PETITIONER, at 7.

[17] Oracle, BRIEF FOR RESPONDENT, at 1.

[18] Oracle,BRIEF FOR RESPONDENT, at 7-8.

[19] “11,330 lines”一词在甲骨文的答辩意见中共出现了12次(包括标题)。相较于甲骨文反复强调行数之巨,谷歌试图渲染其抄袭的占比之小。谷歌指出, Java SE库中有286万行代码,安卓重用的仅是其中千分之五。而安卓代码量约1500万行,这部分代码只占安卓代码量的千分之一而已。

[20] https://www.oracle.com/corporate/blog/pay-no-attention-to-that-man-behind-the-curtain-030920.html

[21] 在盛赞己方法庭之友的同时,甲骨文现任执行副总裁Ken Glueck专门撰文嘲笑谷歌的法庭之友,指出谷歌不能代表科技的声音,毕竟硅谷排名前100的企业中,只有微软、IBM提交了意见书声援谷歌,且微软和IBM都纯粹是基于其自身的利益考量。值得一提的是,微软曾作为甲骨文的盟友,在2013年向联邦巡回上诉法院提交法庭之友意见书,在Java API的可版权性及合理使用问题上均支持了甲骨文。但2015年,微软和谷歌达成了商业合作伙伴协议,随后微软转换了立场。本次微软向联邦最高法院提交的法庭之友意见书中,完全没有论及API的版权性问题,而仅强调了谷歌的行为构成合理使用。IBM和Red Hat联合提交的法庭之友意见书中,则同时主张API不应受保护以及重新实现API的行为构成合理使用。但Ken Glueck抨击道,IBM在十余年间失声,今天忽然冒出来,不过是因为IBM收购了Red Hat后压力过大,希望谷歌赢了此案之后,IBM就能将它自己非兼容Java版本进行商用。参https://www.oracle.com/corporate/blog/is-tech-supporting-google-021720.html,https://tech.sina.com.cn/roll/2020-03-22/doc-iimxyqwa2325421.shtml.

[22] 在美国联邦最高法院受理后,正式又提交了一份由83位计算机科学家署名的法庭之友意见书。

[23] 78 Computer Scientists,MOTION FOR LEAVE TO FILE BRIEF OF 78 AMICI CURIAE AND BRIEF OF 78 AMICI CURIAE COMPUTER SCIENTISTS IN SUPPORT OF PETITIONER,at 18-21.

[24] 78 Computer Scientists,同注23, at 22.

[25] 78 Computer Scientists,同注23, at 17.

[26] 78 Computer Scientists,同注23, at 23-25.

[27] Oracle, BRIEF FOR RESPONDENT, at 57.

[28] Oracle, BRIEF FOR RESPONDENT, at 56.

[29] 78 Computer Scientists,同注23,at 16.甲骨文自己也承认,谷歌抄袭的有一些API对于使用Java编程本身是必不可少的。最初甲骨文指控的是11,500行代码,后来双方同意其中72个类是必要的,因而将其剔除了。这就意味着,让权利人自行划界无法完全消弭纠纷。

Web Design San Francisco