Oracle 赢得对 Google 的 Java 侵权上诉,读懂这则新闻前你需要先知道这些


据彭博社报道,Oracle 和 Google 关于 Java 的侵权诉讼再次 180 度大转弯,上诉法院推翻了此前判决,把案件发回联邦法院审理。此案一波三折,如同肥皂剧一般精彩。跟随本文的梳理,为你展现这一案件的历史进程(-1s)。


0 Java 和 Android 的前世今生

在介绍 Oracle 起诉 Google 之前,有必要介绍下本案的的焦点:Java 编程语言和 Android 操作系统的发展过程。当然,如果你是一名 Java 或 Android 开发者,相信这一部分你已完全知晓。

Java 作为一种广泛使用的计算机编程语言,由 Sun Microsystems 公司(简称 Sun)开发于 20 世纪 90 年代。Java 技术包括了 Java 编程语言、Java 编译器、Java 虚拟机以及丰富的 Java 类库。为了满足跨平台特性,Java 使用了一种叫做 Java 虚拟机(简称“JVM”)的运行平台,从而使代码经过一次编译就可以在不同的操作系统上运行。由于拥有跨平台、面向对象、泛型编程等特性,且伴随着互联网的迅猛发展,Java 广泛应用于企业级 Web 应用开发和移动应用开发,成为一门举足轻重的编程语言。

由于盈利模式的问题,Sun 并没有从 Java 的成功中获取太多利润,反而在 21 世纪之后逐渐没落。2009 年 3 月,传闻 IBM 公司(简称 IBM)与 Sun 公司就收购事宜洽谈,在 IT 界引发轰动,然而在 4 月 6 日 IBM 提出以每股 9.40 美元的报价被 Sun 拒绝,事件急转直下,谈判破局。仅仅过了 15 天,Oracle 公司(简称 Oracle)于 4 月 21 日突然宣布“以 74 亿美元收购 Sun 公司”,每股价格为 9.5 美元,仅仅比 IBM 的每股报价高 0.1 美元,舆论一片哗然。收购 Sun 后,Oracle 也拥有了 Sun 在 Java 上的专利和版权。作为一家颇具开源精神的商业公司,Sun 牵头成立了 Java Community Process (简称 JCP),JCP 以开源社区的身份维护着 Java 的开发工作和执行路线,因此 Sun 也并未从 Java 的发展中获取太多利润。而 Android 的横空出世,似乎让收购 Sun 的 Oracle 公司看到了从中攫取利润的商机。

Android 是由 Andy Rubin 等人在 2003 年成立的一家创业公司,在 2005 年被 Google 公司收购。Android 研发过程中广泛使用 Java 技术,且其编程主要采用 Java 语言。Google 在收购 Android 后曾与 Sun 就 Java 授权事宜展开谈判,但没有达成一致意见。2006 年 2 月份 Sun 提出新方案,让 Google 支付 2 千万美元与 10% 的 Android 相关收益以取得 Java 为期三年的使用许可,遭 Google 拒绝。由于未能与 Sun 就 Java 授权事宜达成一致意见,Google 采取的应对策略是雇佣了一批 Sun 的 Java 开发者,绕开 Java 版权限制开发 Dalvik 虚拟机,并有意让 Dalvik 与 Java 虚拟机指令集不兼容。2007 年 11 月,Google 推出了 Android 系统,并迅速占领了市场的支配性份额,使 Sun 遭受双重打击:既失去了达成一个许可协议的机会,又面临 Dalvik 挤占 Java 虚拟机在嵌入式市场统治地位的威胁。最终,Sun 被 Oracle 收购,而完成收购后,Oracle 就展开了对 Google 的诉讼。

1 堪称肥皂剧的诉讼进程

2010 年 8 月,Oracle 向北加州联邦地区法院提起诉讼。案件由具有编程背景的美国地方法院法官威廉•阿尔索普(William Alsup)主审。Oracle 指责 Google「故意、直接及反复侵犯了 Oracle 与 Java 有关的知识产权」,诉讼理由主要有两点:一是 Google 在虚拟机技术方面对字节码的使用涉及侵权,并提出了 7 件专利中的 132 件权利要求;二是 Google 对 Java 平台的直接和间接著作权侵权。此外,Oracle 还指责与官方代码不一致的 Java 版本破坏了 Java 平台的兼容性,否定其“一次编写、处处运行”的理念,从而降低其价值。

Google 在答辩状中提出了所诉专利无效、未侵权、专利滥用、实质性非侵权用途、公有技术等抗辩,并要求法庭判决所诉专利无效。对于 Oracle 权利要求解释报告,Google 回应:Java 建立于“现有技术”(Prior art)之上,其核心概念、虚拟机均非 Sun 发明,Java 程序语言在 Java 平台创造之前就已经是公知技术并被使用,Java 从现有技术发展而来;Android 与 Dalvik 虚拟机均独立开发,既没有改变 Java,也没有改变 Java 虚拟机,不受 Oracle 兼容性及其他限制的要求。

2011 年 6 月 Oracle 提交赔偿金报告,索赔 14~61 亿美元,Google 对该报告的合理性、科学性提出质疑,要求法官否决 Oracle 的要求;7 月 Alsup 法官采纳 Google 意见,驳回了 Oracle 的赔偿主张,但同意让 Oracle 重新核算赔偿金数额,提出新的赔偿要求。Oracle 提出的高昂赔偿金数额大大增加了本案的关注度,但在后续诉讼中,该金额一度萎缩,从 10 亿美元到后来的 15 万美元,至初审结案,该数值归于零。

2011 年 8 月,双方就邮件证据等问题展开数轮交锋。Google 工程师 Tim Lindholm 曾在一封内部邮件中提出 Google 需要通过谈判来获取使用 Java 的许可权,没有其他替代性方案,该邮件成为 Oracle 指控 Google 故意侵权的重要证据之一。Google 提出“代理人-客户优先权”、“工作产品原则”等理由拒绝提交邮件证据,最终法官裁定邮件不受保护。Google 就该裁定上诉但被驳回。9 月,法官应诉讼双方要求发布命令要求两家公司首席执行官 Larry Ellision 和 Larry Page 出庭作证。虽未能达成最终和解协议,两位高管的介入也在某种程度上扩大了本案的影响力。

2012 年 4 月 16 日,该案正式开庭。此时,Oracle 最初提出的 7 件专利中,5 件已被美国专利商标局宣布无效而撤回。剩下的 104 专利的争议在于 Android 的 Dalvik 字节码指令是否包含「符号参考」;520 专利的争议在于 Android 的 dx 工具中的模式匹配技术是否符合 520 专利“模拟执行”流程限制。

至此,除了两件未决的专利外,待解决的问题就是 Android 系统是否侵权了 Java API 的版权,争议焦点集中于 Java API 的可版权性之上。

2012 年 5 月,法官对该案的不同部分陆续做出判决。11 日,陪审团裁定 rangeCheck 代码(总共约 9 行)、8 份反编译文件,Google 侵犯了 Oracle 的版权;30 日,陪审团做出裁决,Google 没有侵犯剩下的两件专利(104 号,520 号);31 日,法官裁定本案中智能手机系统的 API 属于系统或操作方法,不受著作权保护。在赔偿金方面,法院裁定 Oracle 最多只能接受 30 万美元法定补偿,Oracle 放弃求偿,计划对不利判决提起上诉;Google 反过来向 Oracle 追要 403 万美元诉讼补偿,9 月份法官裁定 Oracle 向 Google 支付 100 万美元,补偿 Google 因此案支出的诉讼费用。

2013 年 5 月,在双方提交的答辩状中,Oracle 已经完全放弃了对专利的上诉,双方针对 Java API 版权争议进行辩论。

2014 年 5 月 9 日,案情又发生的巨大变化,联邦巡回上诉法院部分推翻了地区法院裁决,裁定 Oracle 享有 Java API 的著作权。但上诉法院并没有确定 Google 对 Java API 的使用是否适用“合理使用”原则,而是将案件发回地区法院重审。

2014 年 10 月,Google 向美国最高法院申请调卷令。但最高法院在征询美国总检察长的建议后,最终于 2015 年 6 月 29 日拒绝了该申请,维持上诉法院的裁决。

2016 年 5 月 26 日,地区法院一个由 10 人组成的陪审团经过审议,一致同意此案中 Google 对 Java API 的使用适用“合理使用”原则。至此,案件告一段落,但是 Oracle 并没有完全放弃,于 2016 年 10 月 26 日正式提出上诉。

2016 年 8 月 22 日,Google 在最新的 Android 7.0 Nougat 中,将专利的 JDK 替换成开源方案的 OpenJDK,以彻底解决 Java 的专利问题。



2 Java API 的著作权争议

本案的核心是 API 是否应该受著作权保护以及其合理使用的问题,首先需要理解 API 在编程中的发展历史和作用。API 全称 Application Programming Interface (应用程序接口),是软件系统的不同组成部分衔接的约定,它也是计算机软件的发展历史的缩影。早期的计算机软件编程并无 API 的概念。随着编程技术的发展,功能实现越来越复杂,编程语言也在不断的发展,复杂的软件目标迫切的需要编程人员的密切配合。这就逐渐发展出一些在编程人员之间形成共识的编程思想。其中较为重要的就是将整个软件划分为若干个子系统来分别编程实现,再设计好编程接口,通过程序间的调用,最终完成整个软件的目标。为了降低编程难度,提高编程效率,优良的 API 的设计就显得尤为重要。为了消除编程人员在不同平台下编程的鸿沟,API 的设计形成了很多共性,其在结构(Structure)、顺序(Sequence)和组织(Organization)也趋向统一。本案中,Sun/Oracle 开发了 SunJDK 的类库及 Java API,Google 在 Android 开发初期,为了快速占领移动市场,围绕 Android 形成生态环境,其在开发时兼容了 Java 类库,并与其使用相同的 Java API (共计 37 份程序包,包含大约 600 个类,6000 个方法)。值得注意的是,Android 重写了所有的类库(除忽略不计的 9 行 rangeCheck 代码)。因此,著作权之争只涉及 Java API。




API 是否受保护,还需要明晰著作权的保护范围。在著作权法基础理论中有一项重要的理论即思想与表达两分法,著作权只保护思想的表达而不保护思想本身。也就是说只有作品(思想的表达)才是受著作权保护的。进一步,为了明确两分法,产生了混合原则,即如果一种思想仅有一种或者有限的几种方式表达,该表达也被视为思想而不受保护。但是思想和表达两分法的局限性在于,没有较为实用可行的标准来区分思想和表达。在本案中,也存在地区法院和上诉法院裁判自相矛盾的地方。2012 年,地区法院的认为本案中涉诉的 Java API 不受保护。2014 年,上诉法院推翻地方法院的裁定,认为 Oracle 的 Java API 整体结构具有创造性、新颖性,并且类似于分类学,即 Java API 受著作权保护(但是没有判定是否属于合理使用)。

作为计算机产业最为发达的国家,美国法院从 20 世纪 80 年代就开始审理涉及计算机软件的非文字要素是否受保护的案件,其中比较著名的是 Whelan 公司诉 Jaslow 公司案。在此案中,法院确立了 SSO 法则,认为即使被告的程序与原告的程序代码完全不同,但二者的结构(Structure)、顺序(Sequence)和组织(Organization)相同或相近似,仍构成著作权侵权。SSO 原则将计算机软件中除了其总的用途和功能之外的并非实现这一用途和功能所必需的所有成分都认为是构成了受保护的表达。计算机软件相对于文学艺术作品具有很强的实用性,按著作权法的原理,实用性是不受著作权法保护的,因此将计算机软件的结构、顺序、组织作为著作权客体保护起来,无疑是扩大了著作权的保护范围,在世界范围内也广受诟病。

在本案地区法院的审理中,有编程背景的 Alsup 法官认为 API 程序在概念与功能上只受专利法保护,著作权法保护的是这些方法的表达,从而拒绝了 Oracle 的侵权主张。而且根据上述的思想与表达二分法中的混合原则,Google 为了使 Android 兼容 Java 程序,仅能采用与之相同的编程接口的设计,也就是说只有一种方式编写 API,则该受保护的表达(JavaAPI 的结构、顺序和组织)与不受保护的思想发生了混合,则该表达不受保护。

但是上诉法院的看法与地方法院不同,上诉法院认为,所谓表达方式有限不是“抄袭时”的表达方式有限,而是“创作时”的表达方式有限。换句话说,最初 Sun 公司在编写 JAVA 的 API 时,表达方式很多。其后 Google 公司要使 Android 兼容 SunJDK 中的 API,当然只有一种方法。该情形下,不能因为和功能有结合而就完全放弃对表达的保护。至于是否落入“合理使用”原则,还需要进一步判定,这也是二审法院发回一审法院重审的原因。

最终,2016 年 6 月 21 日,美国加州北区法院陪审团在重审中认定,Google 基于 Java 开发 Android 的行为系合理使用,Google 无需赔偿 Oracle,此案告一段落。

3 硝烟再起,上诉法院做出对 Oracle 有利判决

然后,就是2018 年 3 月 27 日的新闻,Oracle 上诉成功,上诉法院推翻此前判决,再度将案件发回加州的联邦法院审理。问题的焦点仍然是 Google 对 Java API 的使用是否侵权。看来这个问题真的很难回答,连美国的不同法院的看法都不一样。「肥皂剧」还再继续,我们拭目以待吧!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

This site uses Akismet to reduce spam. Learn how your comment data is processed.