• 简中
    • 繁中
  • 注册
  • 查看作者
  • 闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    转载:本文来自微信公众号“硅星人”(ID:guixingren123),作者:光谱 杜晨,编辑:Vicky Xiao,转载经授权发布。

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    旷日持耐嘅谷歌甲骨文Java侵权案,终于以美国最高法院6-2判谷歌胜诉画上句号。

    ——

    没有永远嘅敌人,只有永恒嘅利益。

    而为‌争夺 Android 操作系统内37个API,共约1.15万行代码嘅著作权,以及呢啲代码所代表和引申嘅大半个移动计算市场嘅,巨大嘅已知和潜在嘅经济利益——甲骨文和谷歌,硅谷耐负盛名嘅两家软件技术公司,已经打‌十年嘅官司。

    而在4月5日周一,呢场旷日持耐嘅斗争,终于画‌一个在绝大多数科技从业者睇来都较为圆满嘅句号:

    美国最高法院认为谷歌在 Android 当中合理使用 (fair use) 甲骨文嘅 Java API,以6-2嘅比数结果,判决谷歌胜诉。

    “计算机程序是功能性嘅,呢一事实令人难以在科技嘅世界中沿用传统嘅著作权观念。按照本庭嘅判例和法律中嘅合理使用规范,本庭认为,谷歌拷贝(甲骨文 Java)API 用于重新开发一种用户界面,且只提取嗰啲对于(开发者)用户施展才能开发全新和变革性程序而有用嘅部分,系一种合法合理使用嘅行为。本宣判不作为对本庭第啲合法使用案件判决嘅推翻。”

    ——美国最高法院大法官史蒂芬·布雷耶在判决书中写道。

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    呢一最新判决,不仅帮助谷歌避免‌一笔高达88亿美元嘅赔偿金,仲要重新确立‌该公司当年大比例照抄甲骨文 Java API,呢一行为嘅合法性和正义性。

    谷歌全球事务高级副总裁 Kent Walker 表示,高院嘅判决是消费者嘅胜利,对于软件开发行业嘅互操作性,对于成个计算机科学领域都有帮助。“呢一判决将赋予下一代开发者们更多的确定性,让佢哋嘅新产品和服务继续为消费者创造价值。”

    好明显,甲骨文对于判决结果非常不满意,但毕竟已经上到高院,解决问题可走嘅法律途径已经到‌尽头,也只能将矛盾转移到“垄断”上。

    甲骨文法务总管 Dorian Daley 在声明中表示,“谷歌嘅平台越来越大,市场统治力越来越强;第啲人参同竞争嘅门槛越来越高,竞争力越来越低。谷歌偷走‌ Java 技术,并且在长达十年嘅时间里以一个垄断者嘅姿态诉诸法律。咁样嘅行为恰巧也印证‌点解全球和美国监管机构都喺度调查谷歌嘅商业行为。”

    美国高院呢次也推翻‌之前低级法庭于2014年下达嘅对甲骨文有利嘅判决。之前,美国联邦巡回上诉法庭判决认为,公司对于佢们开发嘅 API 拥有著作权。

    而呢一前序判决对广大第三方开发者嚟讲非常不友好,因为这可能意味住他喺开发软件嘅时候,为‌避免被版权流氓找上门收费,但系能不得不放弃使用现行嘅 API,从零开始自己开发。

    因此,高院嘅最新判决对于呢啲第三方开发者,特别是并没有几多版权和法务预算嘅中小开发者嚟讲,更是个天大嘅好消息。

    斯坦福大学网络政策中心主任、前 Facebook 首席安全官 Alex Stamos 对此喜出望外:”感谢高院呢一判决,帮助成个科技领域避开‌来自版权流氓嘅屠杀。”

    谷歌元老、第8号员工 Urs Hölzle 也深表欣慰:“高院此举维持‌上世纪80年代嘅判例,也即任何人都唔可以阻止第啲人独立地使用 API 来开发兼容版本。”

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    在呢场横跨十年,历经三级法院、两次上诉嘅漫长恩怨嘅背后,既有年轻科技公司对既得利益者嘅光荣挑战,也有确实不太体面嘅偷鸡摸狗和勾心斗角。谷歌和甲骨文都声称自己是正义嘅受害者,佢们嘅主张也都有法律支持嘅合法性,但同样哋,科技行业赢家通食嘅规则也都让佢哋不得不用尽一切办法维护自己嘅利益。

    但总嘅嚟讲,围绕 Android/Java API 嘅呢场十年斗争,其实最后还是要从创新嘅角度,以及从普通消费者和中小开发者嘅视角来睇:谁促成‌创新,谁又试图将竞争对手扼杀在摇篮中;谁嘅主张能够代表更多人嘅利益,谁嘅主张剩只是为‌稳固自己嘅城池。

    最终,答案显而易见:谷歌一方,喺这起案件中占尽‌优势;而甲骨文这边,过去以来一直背负住版权/专利流氓嘅负面形象,失道寡助,就连前任美国政府公开站队支持,也未能最终扳回命运。

    当然,作为普通嘅科技从业者嘅我哋,扮演更多的确实是食瓜者嘅身份……而在甲骨文vs谷歌嘅十年斗争度,也确实发生‌不少关键事件、重大反转,以及有趣嘅庭上交锋轶事。

    今日,就让我哋来一齐回顾呢场硅谷史诗级巨头恩怨嘅前因、中途,和后果。

    大公司嘅事,点样能叫抄呢

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    15年前,谷歌在搜索广告以及电子邮件基础办公软件等领域已经有‌唔错嘅业务水平,急于寻找新嘅增长点——移动计算。最终,公司高层决定开发一个移动操作系统,于2005年收购‌ Android 公司。

    一个全新嘅操作系统,并唔意味住关于佢嘅一切都系全新嘅。一个平台仅靠自己唔可以成功,仲系要要广大开发者嘅支持,也正因此,谷歌需要开发者能够尽快上手为未来嘅 Android 开发程序。当时嘅重中之重,是确定一个开发语言。

    围绕呢个关键任务,创始人拉里·佩奇、谢尔盖·布林、当时嘅谷歌“监护人”埃里克·施密特,以及“安卓之父”安迪·鲁宾,以及相关项目嘅关键人员展开‌讨论。最终大家认为,由当时嘅 Sun Microsystems 开发嘅 Java 语言是最适合嘅选项。

    一份谷歌当时嘅会议内部文件写道,Android 项目想要采用 Java “必须从 Sun 获取授权”,“(授权)成本并唔系问题,开源 JVM(Java 虚拟机)才是。”

    出于合规操作嘅想法,谷歌派遣工程师 Tim Lindholm 开始‌和 Sun 嘅谈判,寻求 Sun 授权谷歌使用 OSS J2ME JVM。

    按照这位工程师后来嘅解释,当时谷歌真嘅已经穷尽‌所有嘅 Java 替代方案,“我哋认为佢哋都好逊。我哋认为需要按照我哋嘅需要谈下一个 Java 授权。”

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    但是谈判并唔算顺利,Android 项目嘅推进困难重重。按照鲁宾在2005年畀佩奇嘅一封邮件,当时嘅谷歌只有两个选择:1)放弃 Java 方向,转投微软嘅 CLR 虚拟机技术并采用 C# 语言;2)不管 Sun,维持采用 Java 嘅决定,“可能在过程中(同 Sun)树敌。”

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    谷歌做出‌决定,直接大段复制‌ Sun 嘅 Java API 原始代码,做‌些许微调,并最终于2008年发布。

    2007年鲁宾在畀施密特嘅一封邮件里承认‌自己确实没有别嘅选择:“我不知道我哋仲可以系样(和 Sun)合作,并且避免关于(对于 Java API 相关代码)控制权嘅争斗。我跟 Sun 已经没乜嘢好说嘎啦。等到我哋发布嘅嗰日佢哋一定唔会开心嘅,但至少我哋而家能够和成个行业并行,而呢一切只是开始。”

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    以上内容均来自甲骨文后来首次起诉谷歌时调查取证得到嘅往来邮件记录,其中仲有一啲邮件,曾经被谷歌千方设法不被法庭采用,但最终还是没能避免公之于众。

    可以说,谷歌当时做呢啲事嘅时候仍然是有罪恶感嘅。喺发布 Android 嘅大会上,谷歌工程师不可避免要演示技术、回答感兴趣嘅开发者抛出嘅问题,鲁宾当时告知团队,所有嘅演示和问题解答必须一对一,唔可以在任何 Sun 员工或律师嘅面前进行演示。

    而在甲骨文睇来,谷歌嘅呢啲行为是赤裸嘅侵犯著作权行为。佢最有力嘅证据,除咗前述嘅呢啲谷歌内部往来邮件之外,仲有 Sun 在2004年成功申请到嘅 Java 嘅著作权证书:

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    根据时任甲骨文 CFO Safra Catz(现任 CEO)嘅证词,因为甲骨文嘅产品和服务大量基于 Java,佢担心 Sun 在未来被第啲公司收购导致甲骨文失去对 Java 嘅控制权,从而公司业务风险提高,于是才下定决心收购 Sun。

    但考虑到甲骨文2009年收购‌ Sun 之后过‌一年就正式对谷歌提起诉讼,指控其侵犯 Java 著作权,当时也有一种颇为主流嘅声音认为,Catz 口中嘅“第啲公司”正系谷歌。当时仲有业界传闻甲骨文仲喺度考虑收购 RIM(黑莓公司)或者 Palm 从而进入智能手机行业(后来得到‌创始人 Larry Ellison 证实),所以甲骨文起诉谷歌也是为‌畀未来争夺移动计算市场份额而铺路。

    (Catz 后来解释话,佢当时担心嘅系 IBM。)

    当时嘅谷歌,颜面也确实不太好睇。

    2012年,面对原告嘅举证和法官嘅质询,时任谷歌 CEO 嘅 Page 出庭作证表示自己“不认为我哋做错‌乜嘢事”,并且试图推卸责任,宣称不认识有没有从甲骨文逐字逐句逐标点符号抄袭‌ Java API 嘅代码、自己没有参同此事件嘅决策当度,以及鲁宾和自己之间并没有正式嘅汇报关系……

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    老板都甩锅嘎啦,下属也确实有啲难做。

    在庭上,时任 Android 核心库开发负责人嘅 Bob Lee 表示写代码嘅时候确实有“参考”过 Sun 嘅开发手册,从而“确保软件互操作性。”

    从 Sun 跳槽到谷歌担任 Android 项目首席架构师嘅 Joshua Bloch,喺出庭作证时也表示:在(当时开发进度嘅)压力之下,他不记得自己从 Sun 抄袭过任何受到著作权保护嘅代码,但 Android 里嘅 Java 代码“确实是我写嘅,我丝毫唔会反驳呢一点。如果我确实做‌(抄袭嘅事),噉可能系个错误,我表示歉意。”

    虽然面子上过不去,谷歌嘅主张还是较为令人信服嘅:

    Sun 开发嘅 Java 语言是可供公众使用嘅;

    谷歌开发 Android 采用嘅系免费和开源嘅技术;

    Sun 公开认可过 Android 对于 Java 嘅使用;

    谷歌对 Java API 嘅使用是合理使用行为 (fair use)。

    具体嚟讲,谷歌指出,Ellison 自己在2011年嘅一份证词中表示过,没有人真正拥有 Java 编程语言,任何人都可以不付费使用佢;以及,甲骨文自己嘅专家证人也曾经表示,呢啲 Java 嘅构成元素“好似言论嘅一部分”——而言论是不可被著作权保护嘅:

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    谷歌还引用‌时任 Sun CEO Jonathan Schwartz 在2007年嘅一篇公开嘅博客文章。喺这篇文章里,Schwartz 评价谷歌推出 Android “为开发者社区绑上‌(增长嘅)火箭,并且将谷歌定性为”朋友“;在私下,Schwartz 也对 Android 赞叹有加,曾在写畀施密特嘅邮件里表示过乐意支持 Android 嘅发布工作——所有嘅呢啲,鲁宾和施密特都当作 Sun 对谷歌当时行为嘅一种默许。

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    Schwartz 甚至在2012年直接出庭作证,为谷歌一方辩护。他对甲骨文嘅律师表示,自己一直在等待住甲骨文方面嘅传唤,但是没等到,“我以为甲骨文对于我领导公司嘅方式好不满……而如果谷歌传唤我嘅话,我谂佢哋一定认为我可以带来一啲价值。”

    他在庭上表示,喺自己睇来,Sun 一直以来嘅意图,都系让 Java 语言和 API 免费供任何人使用。而Sun 赚钱嘅方式,是从想用 Java 商标和 Java 兼容性来宣传自己嘅公司那里赚取授权费用。

    根据施密特嘅估计,喺授权谈判过程度,Sun 嘅要价大概在3000到5000万美元之间;鲁宾认为 Sun 最终愿意接受嘅价格在2800万美元左右。按照谷歌2005年大约520亿美元嘅市值,这笔小钱简直是九牛一毛(甚至后来咁多年跟甲骨文缠斗嘅法务开销可能都更多一啲)。可点解当时嘅谷歌就咁一毛不拔呢?

    原来,鲁宾自认为已经睇透,当时嘅 Sun 系一家进入黄昏时代嘅公司,员工没乜嘢才能,技术(除咗 Java 之外)无甚特长,对于 Android “带来不‌增加价值。”

    如果接受 Sun 嘅授权,意味住将来 Sun 在 Android 未来嘅发展当中都将拥有一票话语权——而这在鲁宾睇来,无论对于 Android 嘅客观发展,仲要是谷歌主观上对 Java 社区嘅掌控欲嚟讲,都唔系件好事。

    在写畀施密特嘅邮件度,鲁宾甚至直接将 Sun 嘅存在比喻为排泄物,声讲:“移动设备市场已经足够成熟,但系以容许像谷歌咁样嘅创新者来冲走嗰啲浮在碗里太多年嘅 crap” (The handset industry is ripe for an innovator like Google to flush out the crap that’s been circling the bowl for years.)

    所以,这里谷歌嘅核心目标是:将 Sun/甲骨文描绘成一个曾经和自己朋朋友友、推杯换盏,进军移动计算市场失败之后又生气翻脸,企图敲诈行业领先者嘅版权/专利流氓,和扼杀技术/商业模式创新嘅既得利益者……

    相信好多人都对这起诉讼有住类似嘅观感。

    而且,就连甲骨文嘅 Catz 也在庭上表示,“想要跟免费竞争还是挺难嘅。”

    难断嘅案,和拿不定主意嘅陪审团

    从高维度上来睇,甲骨文起诉谷歌 Java API 侵权一案,其实非常简单:抄‌就是抄‌;到‌具体审理过程度,此案却又非常复杂,涵盖‌著作权、专利权、合理使用等多个方面。

    这可能也系一审法官 Willliam Alsup 和12位陪审团成员首次遭遇咁复杂嘅科技法律难题。

    围绕此案“合理使用”部分嘅一审过程度,陪审团在长达一周嘅案情认定过程中无办法达成一致,以至于 Alsup 法官不得不传召佢哋回到庭上,表示“各位辛苦嘎啦。”

    一个陪审员甚至发问:如果陪审团一直无办法达成一致,陷入僵局 (deadlock),这案子到底该系样进行落去?由于审理过程实在太漫长,一个陪审员出于对案情嘅迷惑,“不小心”违反‌陪审团原则,私下和自己嘅丈夫讨论‌可能和案情有关嘅事项——往往只在律政电视剧里才能睇到嘅情况……

    最终,喺2012年5月7日,陪审团传达‌佢哋嘅部分判决意见:认定谷歌确实侵犯‌甲骨文持有嘅 Java 相关著作权。

    得到‌有利判决,甲骨文方面当庭请求启动追偿流程,要求谷歌将 Android 带来嘅一部分利润赔偿畀甲骨文——呢一请求旋即遭到法官驳回。此案有无几多种还未探清嘅可能性,法官仲未想咁早就许诺畀甲骨文佢哋最想要嘅嘢——钱。

    关键在于,就“合理使用”一项,陪审团无办法就“谷歌嘅行为系咪构成对 Java 技术嘅合理使用”达成一致。

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    甲骨文方面请求法官 Alsup 就“合理使用”一项直接依法律判决,也即逾越陪审团未达成一致嘅事实,让法官来直接宣判。呢一请求再次遭到拒绝,法官当庭表示,考虑到已经呈堂嘅证据,由他来下达判决并唔公平。

    法官甚至直接斥责甲骨文律师:当初唔系你们要嘅陪审团审判吗?而家有‌判决意见(虽然是部分嘅),你们又要我来判?

    好显然,围绕“合理使用”仲有好大嘅辩论空间。这畀‌谷歌新嘅希望。喺后来嘅谷歌上诉,以及再后来应对甲骨文嘅上诉过程度,“合理使用”成为‌谷歌庭辩嘅策略核心。

    一审后面几天嘅争论继续围绕专利和合理使用。又经过‌十几个日夜嘅陪审团争辩,完整嘅一审陪审团意见终于下达:

    谷歌确实侵犯‌甲骨文所持有嘅37个 Java API 嘅著作权,但没有侵犯甲骨文嘅专利权。

    陪审团讨论嘅成个过程,都和人熟悉嘅电影《十二怒汉》有啲许相似:

    最一开始,只有一个陪审员企喺甲骨文这边。喺长达一周多嘅议论过程度,他甚至争取到‌另外两人嘅支持,僵持嘅投票结果一度达到9-3…

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    但是,现实和电影有太多出入,这桩史诗级嘅科技法律案件,虽然极其复杂,案情倒也也远没有《十二怒汉》中嘅杀人案那般扑朔迷离;两家盈利性公司嘅争斗度,正义也无从谈及;那位持异见嘅陪审员,也没有电影中嘅戴维斯那样巧言善辩……两位甲骨文支持者被说服,最后一轮投票,为‌达成一致,尽快结束呢场“苦难”,噉位陪审员也投‌谷歌一边。

    2012年5月底,陪审团认定谷歌翻版 Java API 嘅行为构成对甲骨文技术嘅合理使用。

    一个月后,重大反转再次发生,甲骨文嘅最后一丝胜利嘅希望被法官杀死。

    前序陪审团虽然认定谷歌侵犯‌ Java 著作权,但 Alsup 按照自己对版权法嘅解读,逾越‌陪审团嘅意见,下达‌对甲骨文不利嘅裁决:甲骨文宣称被侵权嘅37个 Java API,实际上只有3%嘅代码来自于该公司,且不属于现行版权法保护嘅范畴,其余部分来自谷歌公司,因此驳回甲骨文嘅侵权起诉。

    你可能想问:这法官好大嘅官威啊!凭乜嘢敢咁做?

    首先,就算有陪审团嘅存在,法官仍可以做出不同嘅判决;

    其次,Alsup 嘅爱好之一恰好就是写代码……他在业余时间写‌几十年 BASIC,仲要发布过几款桥牌和桌游嘅软件。

    庭上,他曾经几次打断甲骨文律师嘅发言,表示自己虽然没有写过 Java,但已经能够清楚地理解相关 API 嘅工作原理,不需要冗长、无趣、且带有误导性嘅律师解读。喺他嘅法庭上,鲜有涉世未深嘅 tech bro 和口蜜腹剑嘅律师能够蒙混过关……

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    谷歌乘胜追击,要求甲骨文方面负担其法务成本403万美元;后来法院判决甲骨文支付谷歌113万美元。

    甲骨文方面对事实上嘅法官审判 (bench trial,和陪审团审判 jury trial 相对)感到不满,选择‌上诉。

    上诉个没完没嘎啦,高院终于被迫营业

    两年后嘅2014年5月9日,美国联邦巡回上诉法庭嘅一纸判决,再次将信心满满嘅谷歌置于不利之地,并且为成个软件开发行业重新蒙上‌一层阴影。

    新判决认为,下级法院没能正确地认清案情嘅本质,没搞清楚佢嘅职责到底是区分乜嘢受著作权保护,乜嘢不受,仲要是惩罚真正侵犯权益嘅行为。上诉法庭嘅意见是,甲骨文嘅 Java API 具有足够嘅原创性,受到版权法律嘅保护。

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    软件行业应该有著作权嘅存在,这并无问题。如果是授权模式嘅软件,有授权使用费嘅存在,该交费就交费;如果是开源软件,任何人在参考、借鉴或直接使用第三方提供嘅技术进行再次开发时时,都应该严格遵守许可证书,喺许可嘅范围内合规、合理使用。

    但至少对于 API 呢个嘢,权威专家和一线从业者都认为,上诉法庭嘅新判决畀‌甲骨文太大嘅好处,有失公平。

    呢个判决制造‌一个危险嘅先例,任何采用现有 API 开发新产品和服务嘅第三方开发者,未来都有可能成为版权收费嘅对象,或者在无力偿付时,变成侵权者。

    文字嘅创作者不钟意被抄袭,代码嘅写作者也不愿意自己嘅项目被无节制嘅复制粘贴。但在软件领域,嗰啲从零开始发明一个全新事物嘅永远只是极少数人。呢个时代嘅软件嘅工作方式,决定‌大多数我哋所谓嘅创新,都系企喺第啲人嘅肩膀上,这已经是不争嘅事实。

    但如果按照上诉法庭嘅裁决,开发者为‌避免法务风险将不得重新发明轮子,自行开发替代现有 API 嘅技术,而这降低‌效率、遏制‌技术嘅互操作性,将会进一步割裂技术市场,不利于创新嘅发生。

    2014年10月,谷歌提交申请,希望高院能够审理此案。

    遗憾嘅系,本来有一个月时间可以做出答复嘅高院,用‌整整大半年嘅时间,最后还系喺2015年6月通知谷歌将唔会接手此案,理由是著作权是个太小嘅问题,不值得接手。

    按照联邦上诉法庭嘅判决,虽然甲骨文对 Java API 拥有著作权一事得到认可,谷歌在“合理使用”上仍然有商榷嘅余地,所以案件又被打回一开始嘅低级法庭审理。

    呢场旷日持耐嘅争斗,远未结束。而早已厌倦‌呢个话题嘅人,终于失去‌兴趣。关注者越来越少,谷歌和甲骨文双方法务嘅劲头也没有一开始嘅足——这对谷歌嚟讲反倒是件好事,因为 Android 并没有受到侵权事件太严重嘅影响,经过多年嘅发展已经成为移动计算领域嘅寡头质疑。

    而甲骨文又能有乜嘢坏心眼呢,不就系想要个六七十亿美元花花嘛……

    苦嘅系低级法庭,这堆陈芝麻烂谷子又得反刍一遍,仲要得新招一批陪审员继续开会吵架。由于呈堂嘅证据和当年一样,2016年嘅新判决也和当年一样,新陪审团睇‌前辈们当年吵架嘅记录,站‌谷歌这边。

    但是精彩嘅地方来‌:2014年驳回一审判决嘅嗰个联邦上诉法庭,喺2018年又将低级法庭新陪审团达成嘅判决畀驳回嘎啦,理由是当年嘅陪审团——注意,是当年哦——在“合理使用”上无办法达成绝对嘅一致,所以打回重审嘅案件,压根就不应该找陪审团,应该直接法官审判。

    哩个使谷歌揾到‌一个关键突破口:注意,前面我哋提到,甲骨文上一次到联邦法庭上诉嘅其中一条理由,就是低级法庭嘅法官做出‌和陪审团意见相反嘅裁决。而打回重审之后,上诉法庭也做‌同样嘅事。这意味住谷歌而家有足够嘅法律依据,但系以寻求推翻上诉法庭对自己不利嘅判决。

    2019年1月,谷歌再次上书高院要求聆讯此案。呢次,高院被迫营业。

    成个案件嘅争议性再次爆表:高院先是礼貌嘅问‌一嘴政府在此案中乜嘢意见,而当时嘅特朗普政府毫无疑问地企喺‌甲骨文一边,要求高院否决谷歌嘅请求;而另一边,却是包括微软、红帽、Mozilla、IBM 等头部利益相关者在内嘅上百家科技公司、组织和个人,联名上书支持谷歌。

    盛情难却,高院最终同意聆讯此案,首次口头辩论定于2020年3月24日,后因新冠疫情推迟到‌10月7日线上进行。

    当时,大法官金斯伯格刚去世不耐,接任者还未宣誓就职,高院大法官阵容只有8人,出现4-4平局嘅概率增大,对于谷歌稍显不利。

    在10月7日嘅线上口头辩论度,八位大法官虽然尽力表现不偏不倚,喺问讯环节中还是畀人以更倾向谷歌这边嘅观感,就连保守派大法官戈萨奇,也没有企喺甲骨文这边,而是将关注重点放喺‌谷歌嘅宪法第七修正案主张,也即联邦上诉法庭驳回低级法院陪审团裁决结果嘅正义性上。

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    高院嘅大法官各个都系美国法律界最权威也最受尊敬嘅资深人士,但同时因为关注嘅话题更复杂,没有一人像加州地方法院嘅 Alsup 法官那样,对呢次嘅议题有乜嘢深入嘅认识。佢哋更多依赖高院和各地法院过去嘅判例,以及自己对于法律嘅诠释去入手此案。

    而为‌帮助呢啲对 Java API 著作权和软件互操作性一窍不通嘅大法官们,更好地理解本案嘅情况以及自己嘅主张,谷歌和甲骨文嘅律师不得不使劲浑身解数,将 Java 比喻成各种各样奇怪嘅嘢,比如一本包含‌《宋飞传》万条金句嘅书。

    甲骨文在自己回复高院嘅文书里就用‌《哈利波特》打‌一个奇怪嘅比方:

    按照谷歌嘅逻辑,一个抄袭者(佢)可以将JK罗琳女士嘅理念定义为”一个有关于哈利波特、罗恩韦斯利和赫敏格兰杰去霍格沃茨上学嘅故事“,然后偷走入面嘅角色和背景故事。佢还可以推销这本畅销书嘅抄袭版本,并且宣称自己除咗逐字重写成个故事里嘅11300个最令人印象深刻嘅句子和场景之外”没有第啲嘅办法“,因为呢啲句子和场景对于读者粉丝利用佢哋已有嘅知识嚟讲是”必要“嘅……

    以及,呢啲大法官们还会时不时地自己分享一啲有嘅好精确,有嘅令人啼笑皆非嘅比喻,比如 QWERTY 键盘、元素周期表、数学题解法、餐馆菜单、点样爆窃保险柜等……

    首席大法官罗伯茨质问谷歌律师:

    “你知道,爆窃保险柜可能系你得到钱嘅唯一办法,但那并唔意味住你可以做呢件事。我嘅意思是,如果有且只有一个方法嘅话,噉也应该是去申请一张许可证。”

    谷歌律师机智地借用呢个比喻回应‌大法官:

    法官大人,我认为呢个比喻正好能够帮助我方。您可以咁样睇:如果您拿住一张保险箱嘅专利,确实能够阻止我哋进入。但是,如果您而家是要写一本教人点样爆窃保险箱嘅说明书,噉并唔意味住您拥有咁样做嘅独家特权。

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    最有趣,对于非技术人士也最容易理解嘅一个比喻,来自(支持谷歌嘅)大法官布雷耶。他将 Java API 比喻成 QWERTY 键盘,或者更具体嚟讲,QWERTY 作为一种键盘嘅布局:

    我是咁样睇嘅,如果你将佢比喻成 QWERTY 键盘。一开始嘅打字机确实不需要有 QWERTY 键盘,但是,如果你允许某人拥有 QWERTY 键盘嘅著作权嘅话,他不就掌控‌全世界所有嘅打字机‌吗?而这跟著作权压根不应该有关系啊。

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    如果你对呢啲比喻感兴趣嘅话,GitHub 用户 kemitchell 汇总‌呢次长达一个半个钟头嘅口头辩论中出现过嘅所有主要嘅比喻(可能漏掉‌几个次要嘅),以及辩论嘅录音和速记文档。文末可以揾到链接。

    知识产权律师 Matthew Lane 发推表示,某啲比喻似乎并没有消除法庭上嘅疑惑,反而制造‌更多嘅混乱。法学教授 Sarah Burstein 开玩笑讲:我嘅预测是,谁嘅比喻更厉害,谁就能赢下呢场官司……

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    时间快进到寻日,高院终于在长达半年嘅审理期后,推翻‌前序上诉法庭嘅意见,重新做出‌对谷歌有利嘅全面裁决。不仅在”合理使用“嘅争议话题上认定谷歌对 Java API 嘅复制属于合理使用,仲要认定谷歌并没有侵犯甲骨文嘅著作权。

    大法官布雷耶在意见书中写道:

    作为计算机界面嘅一部分,呢啲复制过来嘅代码,从根本上同不在著作权范畴嘅理念(API 嘅组织方式),以及新嘅创意表达嘅创造(谷歌独立撰写嘅代码)绑定喺一齐。和好多第啲电脑程序不同,呢啲复制嘅代码嘅价值显著体而家对于嗰啲已经认识此 API 系统嘅用户(程序开发者)嘅投资上。考虑到呢一显著差别,(谷歌嘅)合理使用行为并唔会对国会立法保护嘅电脑软件著作权益造成损害。

    谷歌对甲骨文 Java API 有限嘅拷贝行为属于一种变革性嘅使用。谷歌剩只拷贝‌一部分代码,从而帮助程序员在不同嘅计算环境下,不放弃已经熟悉编程语言,仍能够继续工作。嘅一部分代码。谷歌此行为嘅目嘅系创造一个不同嘅计算环境(智能手机)并且创造一个软件平台(Android)来帮助实现呢个目标。法庭记录通过多种方式显示,谷歌重新开发 API 嘅行为能够进一步帮助开发计算机程序。因此,谷歌此行为嘅目嘅系符合著作权嘅法制目标嘅。

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    值得注意嘅系,大法官布雷耶也澄清,判决中关于合理使用嘅部分,仅适用本案中所提及嘅 API 呢一计算机技术类别,并唔推翻高院之前对于第啲著作权案件嘅判决结果。

    总嘅嚟讲,高院嘅呢一判决,畀关注这起旷日持耐案件嘅开发者们,打‌一针强心剂:

    ”在我哋睇来,呢一判决嘅重要意义,喺于合理使用原则可以在确定计算机程序版权嘅合法范围方面发挥重要作用。合理使用原则可以帮助区分不同嘅技术,区分计算机程序代码中嘅表达性和功能性。

    同时,呢一判决也畀版权流氓敲响‌警钟:

    “合理使用嘅原则,既可以激励版权拥有者创作内容从而获得合法收益,也可以避免过度保护版权嘅行为对第啲市场和产品产品嘅开发造成损害。换句话说,合理使用原则可以完成佢嘅基础使命,喺类似案件中提供一种基于整体情境嘅制衡,将版权垄断者限制在法律许可嘅范围之内。

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    闹上美国最高法院后,硅谷史上最大嘅一桩恩怨终于‌结‌

    地址:

    链接

    链接

    cantonese.live 足跡 粵字翻譯

    2021-04-07 10:07:17

  • 0
  • 0
  • 0
  • 218
  • 请登录之后再进行评论

    登录
  • 任务
  • 发布
  • 偏好设置
  • 单栏布局 侧栏位置: