谷歌侵权甲骨文 Java 版权案难裁决,已征求特朗普政府意见

局长
 局长
发布于 2019年04月30日
收藏 17

谷歌和甲骨文两家科技巨头在过去十几年里一直存在竞争,但真正结下过节还是源于甲骨文对谷歌的诉讼。根据甲骨文的说法,谷歌的 Android 操作系统未经许可使用 Java 相关技术是对甲骨文版权的侵犯(非法使用了 37 个 Java API 用于 Android 操作系统)。

甲骨文最初于 2010 年起诉谷歌,一度在该案中寻求来自谷歌高达 90 亿美元的侵权损害赔偿。

不过直到现在该案仍没最终的裁决结果,因为对「API 是否受版权保护」的裁决将会对软件行业产生深远的影响。

据路透社的报道美国最高法院今日已向特朗普政府就“谷歌要求最高法院对与甲骨文之间的版权纠纷案(copyright dispute)进行 review”这一请求征求意见

事件回顾

2010年,甲骨文以 74 亿美元收购了 Sun(Sun 于 1995 年开发了 Java),然后在不到8个月的时间里便起诉谷歌侵犯了关于 Java 语言的版权,索赔 88 亿美元。

甲骨文认为谷歌用于 Android 系统的 37 个 package 中的 Java API 是对 Oracle JDK 的侵权。37 个 package 如下:

java.awt.font
java.beans
java.io
java.lang
java.lang.annotation
java.lang.ref
java.lang.reflect
java.net
java.nio
java.nio.channels
java.nio.channels.spi
java.nio.charset
java.nio.charset.spi
java.security
java.security.acl
java.security.cert
java.security.interfaces
java.security.spec
java.sql
java.text
java.util
java.util.jar
java.util.logging
java.util.prefs
java.util.regex
java.util.zip
javax.crypto
javax.crypto.interfaces
javax.crypto.spec
javax.net
javax.net.ssl
javax.security.auth
javax.security.auth.callback
javax.security.auth.login
javax.security.auth.x500
javax.security.cert
javax.sql

在这 37 个 package 里,谷歌在类和方法的命名,以及功能设计上,完全和 Oracle JDK 一样。为此,甲骨文作为 Java 的版权所有者,认为谷歌的做法属于侵权。

不妨回顾一下甲骨文和谷歌的这场 Java 版权案拉锯战:

  • 2010年,甲骨文起诉谷歌,称谷歌 Android 操作系统未经授权使用了 Java API

  • 2012年,谷歌成功让法庭认可了 API 不在著作权保护范畴内的观点,地方法院裁定 API 不受法律保护,并驳回案件

  • 2012年,甲骨文不满裁决,并上诉至美国联盟上诉法院

  • 2014年,上诉法院三名法官意见一致地将地方法院对该案件的判决驳回,并宣布 API 受著作权保护

  • 2014年,谷歌不服判决便发起上诉,并上诉到了联邦最高法院

  • 2015年,联邦最高法院驳回谷歌的上诉,并将本案发回地方法院重审

  • 2016年3月,甲骨文将索赔金额提至 93 亿美元

  • 2016年4月,谷歌 CEO 与甲骨文 CEO 和解会议失败

  • 2016年5月,旧金山地区法庭进行二次审理,认同谷歌对 Java API 的使用受“fair use”原则保护

  • 2016年10月,甲骨文在联邦巡回上诉法院提起上诉

  • 2017年,联邦巡回上诉法院审理了甲骨文的上诉

  • 2018年3月,联邦巡回上诉法院认定 Android 侵权,判决甲骨文胜诉

  • 随后谷歌再次发起上诉,但2018年8月被驳回

  • 2019年1月,谷歌要求美国最高法院对它与甲骨文之间的 Java API 版权诉讼案做出最终裁决

可以看到,第二次判决中,旧金山地区法庭认同谷歌对 Java API 的使用受“fair use”原则保护,但经甲骨文诉讼后,联邦巡回上诉法院认定 Android 侵权,判决甲骨文胜诉。而最后的这次判决正是推翻了「谷歌对 Java API 的使用属于 fair use」这一论点。

所以甲骨文和谷歌的这场版权纠纷案真正讨论的问题是两个:API 是否应该有版权保护?谷歌对 Java API 的使用是否属于 fair use。根据美国的版权法,只要是在 fair use 的范畴内使用受版权保护的内容,无须通过版权所有者的同意。

谷歌方面认为裁决结果将会对计算机行业产生深远影响。因为 API —— 标准化的软件接口驱动了软件领域的创新,它们能够让计算机程序相互交互,让开发者轻松地为不同平台构建技术。因此希望最高法院能明确裁决 Java API 是否受版权保护。

裁决结果会有怎样的影响呢?这里可以举一个例子。Wine 是一个开源项目,它能够在多种 POSIX-compliant 操作系统(诸如 Linux,macOS 及 BSD 等)上运行 Windows 应用的兼容层。而为了允许用户在 Linux 和其他操作系统上运行 Windows 程序,Wine 实现了 Windows API —— 尽管这是通过逆向工程实现的

如果在这场诉讼案中,最高法院判决甲骨文胜诉,那么按照美国法律的判例法,只要微软希望,他们理论上仍可以对 Wine 项目采取行动 —— 利用这些受版权保护的 API 去起诉 Wine。

所以对于这场长达十年的拉锯战,最高法院也犯难了。为此,最高法院今日向特朗普政府寻求帮助,是否还要继续审理谷歌的上诉。

对于某些特定案件,美国最高法院有时会向政府征求意见。2015年,联邦最高法院曾驳回谷歌此前在该案中提出的上诉,正是因为听取了奥巴马政府领导下的司法部的建议。

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 OSCHINA 社区 [http://www.oschina.net]
本文标题:谷歌侵权甲骨文 Java 版权案难裁决,已征求特朗普政府意见
加载中

精彩评论

此网页不存在
甲骨文必须败,要是赢了那it行业就别玩了,对行业不仅没有帮助,而且极大阻碍进步。
ChengShuai
ChengShuai
其实一直不是很明白,他们说的这个api指的是函数名,还是依赖库?如果是依赖库,我觉得确实需要授权,但如果是函数名的话……比如,main函数的版权应该在谁那里呢?
弦歌
弦歌

引用来自“ChengShuai”的评论

其实一直不是很明白,他们说的这个api指的是函数名,还是依赖库?如果是依赖库,我觉得确实需要授权,但如果是函数名的话……比如,main函数的版权应该在谁那里呢?

引用来自“非仙”的评论

这件事关键就是山寨合不合法, 比如linux是山寨unix并且api完全兼容, 而计算机历基本就是山寨历, 如果判为不合法那乐子就大了
不知道就不要乱讲!linux并不是山寨unix,而是早在linux还没诞生前,就已经有了操作系统接口方面的国际标准,IEEE早在80年代就发布了POSIX(可移植操作系统接口),定义了一系列标准,来保证不同操作系统之间的可移植和可互操作性。所以linux即使底层代码完全和unix不一样,但接口是兼容的。包括windows NT,内核实际上也大部分兼容POSIX,之所以现在windows不再像Unix,是微软做的改动多,而不是说不能兼容。linux是开放源代码的,unix的源代码也被扩散和用于学习,而且之前Unix的版权方SCO素来以严苛著称,以这样严格的知识产权保护,linux都没有侵犯Unix的知识产权,可想而知,linux完全不是用“山寨Unix”能说得通的,二者的底层代码是完全不同的两套东西,只是做出来的接口是一样的而已。
雲霏霏
雲霏霏
吓的我们赶紧抛弃Java转.NET
扫地农
扫地农
看见没 9行代码多贵 所以写代码时多写些异常捕获 这样日后可能是个宝藏!

最新评论(49

妙木山的大贤者
妙木山的大贤者
个人看法是 Google 会败诉,毕竟 Android 虽然用了 JVM 但是不完全兼容 Java 字节码,这点让我想起了很多年前,Sun 还没有被甲骨文收购的时候,以差不多的理由诉讼微软的 Visual J++ 并取得胜利的结果,这也让巨硬不做自己的 Java 虚拟机而是做了一套 .Net。
点滴心语
点滴心语

引用来自“雲霏霏”的评论

吓的我们赶紧抛弃Java转.NET

引用来自“肖滔”的评论

@雲霏霏 .NET更不要玩了,官司都没得打,直接缴费

引用来自“久永”的评论

以前的确是这样,所以大家都不和他玩了。
所以现在收敛很多,浪子回头。
但是有了前科,开源界的他的信任不会马上就来的。
甲骨文这么玩,以后也会被大家这样抛弃。
不知道谷歌会不会也走这条老路。
没有永远的朋友,只有永恒的利益
Sandsli
Sandsli

引用来自“YANG_YAWEI”的评论

表面上说 api 应该免费,可实际上都在其他地方把钱交了,比如微信开发,要使用微信的 api 你其实是给了腾讯钱的,只不过腾讯没有像 oracle 这样直接提出来罢了
确实 使用API 要企业资质 每年年审 都是钱啊
谁来与我大战三百回合
试用接口当然也是侵权。比如我生产一种6口插座,专门用来插我自己生产的机器假设为A(Java),并申请专利,这种6口插座不同于市面上的2口和3口的。后来有家公司生产了另一种机器假设为B(android),也想用6口插座的,目的是为了让那些已经使用6口插座的人(已经有几千万人了),继续使用现有的插座,节省学习和安装的时间。
s
sikele2237
谷歌你看unity3d用mono用的多好,干脆把xamarin.forms拿去用吧,xaml那套不知道比axml那套爽多少了。
陈钇蒙

引用来自“ChengShuai”的评论

其实一直不是很明白,他们说的这个api指的是函数名,还是依赖库?如果是依赖库,我觉得确实需要授权,但如果是函数名的话……比如,main函数的版权应该在谁那里呢?

引用来自“非仙”的评论

这件事关键就是山寨合不合法, 比如linux是山寨unix并且api完全兼容, 而计算机历基本就是山寨历, 如果判为不合法那乐子就大了

引用来自“弦歌”的评论

不知道就不要乱讲!linux并不是山寨unix,而是早在linux还没诞生前,就已经有了操作系统接口方面的国际标准,IEEE早在80年代就发布了POSIX(可移植操作系统接口),定义了一系列标准,来保证不同操作系统之间的可移植和可互操作性。所以linux即使底层代码完全和unix不一样,但接口是兼容的。包括windows NT,内核实际上也大部分兼容POSIX,之所以现在windows不再像Unix,是微软做的改动多,而不是说不能兼容。linux是开放源代码的,unix的源代码也被扩散和用于学习,而且之前Unix的版权方SCO素来以严苛著称,以这样严格的知识产权保护,linux都没有侵犯Unix的知识产权,可想而知,linux完全不是用“山寨Unix”能说得通的,二者的底层代码是完全不同的两套东西,只是做出来的接口是一样的而已。
现在谷歌和甲骨文不也是linux和unix的问题吗,jvm的api设计就在那里,你实现一个和我实现一个有啥问题?不过好像sun有要求过第三方的jvm必须做到能兼容所有字节码,否则会造成jvm生态割裂,android那个虚拟机明显没做到字节码兼容
久永
久永

引用来自“雲霏霏”的评论

吓的我们赶紧抛弃Java转.NET

引用来自“肖滔”的评论

@雲霏霏 .NET更不要玩了,官司都没得打,直接缴费

引用来自“久永”的评论

以前的确是这样,所以大家都不和他玩了。
所以现在收敛很多,浪子回头。
但是有了前科,开源界的他的信任不会马上就来的。
甲骨文这么玩,以后也会被大家这样抛弃。
不知道谷歌会不会也走这条老路。

引用来自“肖滔”的评论

@久永 谷歌应该不会,他的收益模式更多
没人会嫌钱多,而越有钱对盈利的预期和压力越强烈(资本主义制度本身机制导致)。
zhuliu
zhuliu

引用来自“MGL_TECH”的评论

看见没 9行代码多贵 所以写代码时多写些异常捕获 这样日后可能是个宝藏!
但是它可以通过公司招聘找出来你是用的java
冰雪情缘l
冰雪情缘l

引用来自“此网页不存在”的评论

甲骨文必须败,要是赢了那it行业就别玩了,对行业不仅没有帮助,而且极大阻碍进步。
我要告你,你居然也使用 class,还有 if, for, return ,和我很多地方相似,等着收律师函吧
d
dwcz

引用来自“烈冰”的评论

不是说司法独立吗,还征求什么意见

引用来自“dwcz”的评论

司法独立,不要意味着独断专行。自主和合作不是对立的。

引用来自“太空堡垒”的评论

只能说是有选择性的。并不完全独立。合作完全可以向法律人士,技术人士进行专业内容咨询,然后做出判断?征求意见意味着将判断权交于别人,而且还是三权分立之一。
哈哈哈,这个问题法律人士和技术人士不一定能做出“决定”,有时无关的人才能做出“决定”。再说,面对这个问题,不论谁做出这个决定,都难做出好决定。
返回顶部
顶部