Oracle与Google的判决书概要
一大早听到了各种各样的有冲击性的消息,真是不平静的第一季度的最后一天啊。关于Oracle与Google的官司,我很在意其中到底还有些什么问题,所以我试着略读了一下判决书。
过程
- 2010年8月Oracle告了Google。当时争论的要点是侵犯专利。(publicKey1)
- 2012年4月旧金山联邦法院开始诉讼
- 2012年5月陪审团判决Google没有侵犯专利。但是fair use (US trademark law 美国商标方案)持不同意见
- 2012年6月Oracle对Google的Java/Android诉讼,协调成专利损害赔偿金为0。没能保护到这次讨论的37件Java API的著作权
- 2012年oracle不服“不承认java API是著作权的对象”的判决。再次上诉
- 2014年5月,控诉法院颠覆地方法院的判决,承认API是著作权的对象。这些API的使用是否符合Google主张的fair use的审理,被打回地方法院重审
- 2014年谷歌上诉美国联邦最高法院
- 美国联邦最高法院驳回谷歌的上诉申请
一度还有对Google有利的裁决,但之后由于oracle的上诉,Oracle的主张得到了认可,API得到了著作权保护。然后Google再次上诉,于是出现了现在成为新闻的,最高法院驳回谷歌的上诉申请(www.askmac.cn )。
至此的著作权以及软件
在这次的资料中,也会不断谈到以前的缘由,以及相关的话题。关键是软件操作(method of operation)无法成为著作权保护的对象这个话题。在此链接之前的资料中,因为这个判决,所以软件的保护是面向于讨论使用了从著作权到专利的保护的方向。
另外, fair user认为API是可以自由使用的。ReactOS以及wine(Linux上虚拟化Windows应用程序的软件)等实际应用中没有问题,也被拿过来引证这个观点。
2014年5月的判決
由上述的理由,我们认为,之前讨论的37个java API package的申明代码以及结构,排列、以及组织是享受著作权保护的。因此,我们在此为了回复陪审团之前的判决,在此撤回地方法院关于著作权相关的判决。陪审员因为也关系到fair use,所以我们在这个判决上的观点是一致的,并且驳回Google的fair use保护相关的上诉。
关于Google的上诉,现在我们作为地方法院确认执行以下决定:
(1)Google执行8个java文件的反编译,并复制到安卓系统中这一行为导致的相关法律问题,我们支持Oracle的主张。
(2)在此驳回要求rangeCheck相关的法律问题的判决的Google的上诉。
上次的判决中,对全世界都造成冲击的的地方是,在fair use 的观点中,被认为API是可以自由地利用的,这个观点是引自“著作权保护也有其所享受的权利”——这个至今为止没有过的司法裁决。
另外,附加条例中还下达了关于反编译以及rangecheck函数(timsort中使用的算法盗用嫌疑)等对于Google不利的判决。
declaring code、implementing code以及SSO
在本文中,将引用具体实例来进行详细解说。其中,最开始的是”declaring code”,接下来的块是”implementing code”。如果是C/C++的话,就应该前者是头文件,后者是源文件(模板库等情况也没有例外)。
public static int max(int x, int y) {
if (x > y) return x;
else return y;
}
在判决中,我们可以发现一部分反编译以及算法有盗用嫌疑,但99%的代码相关的讨论中,却没有发现这些内容。是否实际应用了Clean room这点,在资料中也没有在资料中提到。至此讨论的重点都在于 “逻辑”上,这次主要讨论的点在于declaring code。就是所谓的API。有7000行的declaring code 的直接复制的。
另外,据说还有Structure, Sequence, Organization(SSO)也是复制的。Oracle认为,不仅是包含在逻辑中的代码,从declaring code中导出的软件的结构等理论结构也被模仿(非直接复制)了。
2015年6月的判决书
结果很简单,驳回上诉。
观察至此的内容,会发现很多有意思的讨论结果。
Google主张declaring code是对应17 U.S.C. Section 102 (b)的
“In no case does copyright protection extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery” that is “described, explained, illustrated, or embodied” in the work.
但实际这是错误的(that argument is incorrect),这里的条文如下所示,
Although a book on how to build a bicycle may be eligible for copyright protection, that copyright does not include any exclusive right to practice the bicycle-building method that the book explains; nor can the author prevent another person from writing a better book with a clearer explanation of the same process.
这是限定著作权使用的范围的,并不是否定declaring code本身的著作权的产物(www.askmac.cn )。
Unlike many of the cases that have been the subject of reported appellate decisions, this case does not involve the copying of code for an ordinary computer program.
另外,这还表示著作权侵犯中,不包含代码的复制。
As a result, the parties and the courts below have devoted considerable attention to questions—such as the distinction between declaring code and implementing code, the technical significance of various features of the Java Standard Library, and the degree to which Java programmers possess familiarity with respondent’s pre written methods—that may have little significance in more common disputes
The Court’s resolution of this case therefore might not cast meaningful light on the proper resolution of more typical copyright-infringement cases involving computer programs.
上文中还有这样的意思:本次对这个问题进行了深刻讨论——习惯了java标准library库以及工具的java程序员,为了能够即刻使用,于是复制了API,oracle则通过继续研发java而抢夺了一直以来的生态系统。
“即使有今日的判决,也不代表今后API也一定会受到著作权保护”。换言之,这次是得到著作权保护的特例吗?
总结
这里的意思也似乎并不是完全颠覆“API不是著作权保护对象”这个前提,但可以看出这次的主旨是——“根据情况不同,权利也可以得到伸张。但在剥夺对方Platform平台的竞争力的规模下,API的利用超出了fair use(公正使用,美国商标法案)的范畴。”
虽然这是一场外行们在讨论 API如何如何的诉讼,但让我们留下深刻印象的是,这次并不是用意思暧昧不明的API这个术语,而是使用declaring code这个以java为前提的具体的术语。强调java的标准library的「structure, sequence and organization」的是,与最后判决之前所说的那样,因为这个判决会作为前例,在今后的诉讼中,影响会波及全业界,所以最后还在强调“java的标准library库这个例子最多只用于这次的案例中,并不应用与之后其他的判决”(www.askmac.cn )。
虽说如此,至少有一点,在java的37个package的7000行的声明语句中,承认了API的著作权。已经出现了很多以java这门语言为基石,去理解java的思想的开发者了。在美国的定义中,著作权法并不是保护创意的产物。创意具体而言就是17 U.S.C. §102 (b)的「any idea, procedure, process, system, method of operation, concept, principle, or discovery」,而这次的逻辑是declaring code却既不是创意也不是著作,所以不是fair use。
因为这不适用于java之外的其他案例,是抽象度很高的判决,所以在之后相似的案例中,不站在当时的角度,仅凭今天的判决结果,也是无法预测未来会怎样判决的。
Leave a Reply