最近一桩争讼十年的案子，因临审将近又被大家翻出来，就是甲骨文和 Google API 侵权之争。
这桩案子起源于 2009 年，甲骨文斥资 74 亿美元收购发明 Java 的 Sun Microsystems。次年甲骨文对 Google 提告，理由是 Android 非法複製 1.1 万行程式码，侵犯了 Java 专利。
Google 自然不服。于是过去十年，两大公司从美国旧金山联邦法院，辩论到联邦巡迴上诉法院，再到最高法院，双方轮流不服，轮流上诉。
从 Google 视角来说，经历一审胜诉、二审败诉、最高法院拒绝审理、再审胜诉、再再审败诉。最新的消息是，最高法院计划 3 月 24 日再审。
这场诉讼在网路、媒体也是讨论得沸沸扬扬。近日，外媒 arstechnica 报导，甲骨文发家史其实就是一部抄袭史，透过抄袭 IBM 的 SQL 发财。甲骨文发言人回应，绝无此事。
这到底是什幺故事？
十年官司，轮流上诉
这场史诗级版权官司，不仅因双方耗费漫长时间和金钱──过去有几桩类似版权案件都不了了之，可能会让 Google 损失数十亿美元，且这桩案件将对整个软体业产生巨大影响，Google 提醒美国最高法院，甲骨文有可能成为垄断势力。
先简单回顾一下官司史：
- 2010 年，甲骨文控告 Google 侵犯 7 件与 Java 相关的专利和版权，要求Google 赔偿数十亿美元。
- 2012 年 5 月，美国旧金山联邦法院（或称加州北区法院）法官裁定，Java API 不受版权保护，任何人都可以免费使用；10 月，甲骨文上诉。
- 2014 年，美国联邦巡迴上诉法院推翻一审部分结论，称必须尊重软体的版权保护。
- Google 上诉，2015 年 6 月，美国最高法院拒绝受理 Google 上诉。官司重返旧金山联邦法院，由该院就 Google 另外提出的「合理使用」观点庭审。
- 2016 年 5 月，旧金山联邦法院複审，判决 Google 行为合理，免付版权赔偿。
- 甲骨文上诉，2018 年 3 月，上诉法院再次裁决 Google 侵权，甲骨文索求 88 亿美元赔偿。
- 2019 年 11 月，在 78 名电脑科学家陈情下，美国高院受理 Google 上诉，将複审之前裁决。
读者或许注意到，旧金山联邦法院和上诉法院十年内分别坚定支援 Google 或甲骨文，是这场拉锯战持久的原因。
甲骨文诉讼点不是 Google 抄袭 Java 语言，而是使用过界，没协定的情况下抄袭版权属于甲骨文的 37 个 Java API 段。所以这场漫长官司焦点在于，API 是否也受版权法保护，或者说在多大程度获得版权保护。
Google 理直气壮地表示，没有做错任何事，因版权法版权保护并不包括「系统」和「作业方法」。Google 认为，複製的 Java 方面──函数名、参数类别等──完全符合这些例外，版权的合理使用原则允许这种複製。根据加州联邦法院纪录，Google 从 Java API 複製 37 包、616 个物件类和 6,088 个函数。
电脑软体保护边界一直是很难判定的问题。起初多数国家并不赞成版权法保护程式，美国是最早推动者，在强大的政治与经济压力下，各国逐步接受程式应当作作品受保护。电脑程式分为起源程式和目的程式。API 介于起源程式和目的程式。
关于 API 该不该受保护，网友 @ozzee 表示，「就像你无法给字典版权，也无法给 API 版权。如果我拥有所有英语单字的版权，且我要求你必须使用我的纸张、空气和装置说出这些单字，你会怎幺想？给 API 版权，一个开发者就会被 API 供应商束缚。」
软体业都很关注这起诉讼，不少公司都站在 Google 这边。微软、IBM 曾警告，甲骨文可能会给产业带来混乱。如果複製是侵权行为，不仅会给许多软体公司法律方面的麻烦，还会对用户不利。APIs 广泛存在于软体业，这使相互竞争软体产品也可以互相操作，这意味着用户转换成本更低，软体新创企业进入门槛也更低，因为如果新产品与用户已知道和使用的软体产品相容，就更容易销售。
今年 1 月，Google 提交名为「friend of the court」的法律档案简报，其中 Mozilla、Medium、Cloudera、Reddit 等公司都呼吁联邦法院应允许 API 继续不受版权保护，或说合理使用。
甲骨文其身不正？
而控告 Google 抄袭 Java 之前，甲骨文或许还要先收拾一下自己不光彩历史。外媒 arstechnica 报导，甲骨文的发家史其实就是一部抄袭史，透过抄袭 IBM 的 SQL 发财。如果属实，这些历史与现在 API 版权问题立场无疑矛盾，不利胜诉。
软体公司一直在複製竞争对手的 APIs。如果有人该理解这种複製的重要性，那必然是甲骨文。甲骨文在 1970 年代开始销售的第一款产品就是基于当时新的 SQL 程式库。而 SQL 是 IBM 发明，甲骨文似乎没有获得使用许可。
讽刺的是，如果甲骨文赢了这场法律战，也就是扼杀 40 年前的自己，未来的新创企业将无法像甲骨文 40 年前──产品能与成熟竞争对手相容，将互相操作性当成卖点。
arstechnica 认为，甲骨文複製 SQL 与 Google 複製 Java 非常相似。为什幺这幺说？
SQL 语言看起来长这样：select customer_name, ship_date from orders where product_id=17 and state=’CA’.
从上可知，第一，SQL 有个简单、类似英语的语法。没有程式设计或程式库管理背景的人可透过阅读这个叙述大致了解作用。第二，SQL 是申诉式程式设计语言（Declarative Language）：用户指定在搜寻什幺资讯，但让程式库系统决定如何找到这些资讯。也就是说，SQL 是对非程式设计师出身者友善的语言，稍加练习，就可编写 SQL 查询完成简单工作。
1974 年，一小群 IBM 研究人员在 System R 套装软体实现这些想法。与此同时，IBM 的研究人员发表了说明工作的研究论文。这些出版物非常详细，包括完整的 SQL 语言规格。System R 做出来了，但接下来几年就只在 IBM 内部使用。直到 1980 年代初，IBM 才对外提供基于 SQL 的商业程式库。
▲ Larry Ellison。
而约 1977 年，Larry Ellison 和联合创始人发现了 SQL 语言，他们当时开设名为 Software Development Laboratories 的软体谘询公司，然后想转型为程式库销售公司。Larry Ellison 意识到，如果甲骨文程式库能与 IBM 的 SQL 标準完全相容，可信度会更高。
SQL 设计者 Donald Chamberlin 1995 年接受採访，提到 Larry Ellison 在 1978 年打电话给他，想了解更多 IBM 研发 SQL 的细节，包括错误程式码值。
Chamberlin 本人很乐意分享，但他的老闆拒绝，表示错误程式码要保密。
不过因 IBM 的白皮书有足够细节，足以複製 IBM 的程式库技术，甲骨文在 1979 年发表第一版程式库，当时反覆宣传此产品起源于 IBM。「甲骨文的用户介面就是 SQL」，某位早期甲骨文行销说。
因为比 IBM 提早两年上市，甲骨文立即声名大譟，并在未来几年保持 SQL 程式库领导者地位。
后来 System R 内部还讨论过 IBM 公布 SQL 细节是否错误，这让甲骨文吃掉许多本属于 IBM 的市占率。但也有内部人士认为，发表研究论文之后，才让 IBM 意识到这项技术很重要，所以一开始就很认真对待。
「如果我们没有发表那些论文，它就会失败，」1995 年 IBM 老员工 Mike Blasgen 说，「IBM 很有可能捨弃它。」
一直以来，甲骨文都没有尝试从 IBM 获得 SQL 许可，相关人员似乎都认为甲骨文不需要许可。
Google 与 Java 的过往
Google 不管怎幺说都曾尝试与 Sun 建立授权关係。2005 年 8 月，Google 低调收购 Android ，开始研发手机作业系统，同年 Google 找过 Sun Microsystems 讨论许可协定，并达成暂时协定──Google 向 Sun 支付 2,800 万美元（一说是 4,000 万美元），获得与 Java 相关的专利、Java 商标和其他资产的使用授权。另外，Google 坚称，从未尝试获得 Java 介面版权，在他们看来，法律对此并没有要求。
但协定很快破裂，Google 后来称主要原因不是价格，而是 Sun 对 Android 平台发展的控制力超出 Google 的意愿。因此，Google 决定在没有 Sun 许可的情况下构建自己的 Java 版。
这意味着 Google 要从 Java 语言的功能规範开始，也就是 Java 语言的规则，包括关键字、语法及标準函数的名称和参数类别。Google 没有像甲骨文複製 SQL 複製这些功能的程式码，工程师从头开始编写程式码，并产生与 Sun 的 Java 程式码相同的结果。
Google 后来宣布 Android 是基于 Java 语言时，Sun 首席执行长 Jonathan Schwartz 当时还挺高兴的，他公开表示，「我只是想和其他同事一起衷心祝贺 Google 推出新 Java / Linux 手机平台 Android。」
可能是力量悬殊，总之 Sun 当时并没有找 Google 麻烦，而 2009 年被甲骨文收购后，立刻变了态度。2010 年 1 月，Sun 交易结束，不久甲骨文就控告 Google。当年 1 月，多位前 Sun 高层从甲骨文离职，包括前首席执行长 Jonathan Schwartz、XML 发明人 Tim Bray、前 CTO James Gosling，其中 Tim Bray 加入 Google Android 开发团队。
对比 Google 和 IBM，有满大的差别：Google 複製 Sun 已问世的产品，甲骨文複製 IBM 尚未发表的产品，从 IBM 白皮书学来。
Cornell Tech 法学教授 James Grimmelmann 今年 1 月接受採访时表示，从版权角度来看，两者没有太大差别。如果複製 API 侵犯版权，那幺从档案複製 API 也侵犯版权。根据版权法，IBM 的论文是「受保护的作品」。「如果 SQL 规格有版权，那幺无论从软体还是白皮书複製，版权法都适用。」
甲骨文一直以来的控诉点是 Google 抄袭甲骨文 API，可能在他们的视角，自己複製 SQL 与 Google 複製 Java 不同。
1979 年，IBM 的 SQL 确实还没有庞大的支援程式库供甲骨文複製。因此，甲骨文这套「语言複製」可以、「API 複製」不行的理论倒也符合他们的立场。
但 Grimmelmann 认为，程式设计语言和 API 之间在法律区别对待没有意义。「SQL 本质是通用程式库 API，有 9 个核心动词、参数，以及一些格式和语法。」
目前尚不清楚版权法会怎幺区分核心语言和 API。例如执行加法运算时，Java 可能要求用户呼叫这 API 函数：n=sum(a, b); 而不是透过 n=a+b;。如果版权法要保护前者，后者象徵式「+」也应该得到保护。
基本上说，API 是电脑程式相互通讯的语言，像 SQL 或 Java 等语言也可说是 API 之一。成熟的电脑语言往往比其他 API 有更複杂的语法规则，但潜在版权元素：关键字、参数类别、语法规则很多都相似。如果 API 的函数名称可受版权保护，那幺电脑语言的关键字似乎也可受版权保护，包括「select」、「from」和「where」等 SQL 关键字。
另外，为了减低版权影响，2016 年 Android 7.0，Google 捨弃了私有 SunJDK 转用开源 OpenJDK；2017 年 I/O 大会，Google 宣布 Kotlin 取代 Java 成为 Android 一级开发语言。两年后 Google 表示，超过 50% 专业 Android 开发人员使用 Kotlin 开发应用程式，最新 Stack Overflow 开发人员调查，Kotlin 列为第四大最受欢迎程式设计语言。
一边倒批判甲骨文
对外界批评其抄袭 SQL 的言论，甲骨文并不认可，称「把苹果和花椰菜放在一起比，完全脱离事实，这是不正确的假设。」
这还没完，执行副总裁 Ken Glueck 在官网发表题为《别理躲在幕后的人》（Pay No Attention to That Man Behind the Curtain）一文，言辞犀利，炮轰 Google 和支持者，「装出获得大规模支持的现象，但背后可能不过是利益交易。」
「这不是关于创新，而是窃盗。」Glueck 表示，在软体业，窃取其他开发人员的软体程式码并不常见，而一些複製行为也是版权者出于双方利益一起合作，Java 并不是拒绝选择，而是授权许可在版权方手里。
「Google 尝试寻求外部团体支持，拉拢其他公司登上 friend of the court 简报，製造案件有重大意义和争议、甲骨文的诉求阻碍创新的印象。」
他还提到 Google 递交的 26 份简报，其中 7 份实体有从 Google 获得「实质性贡献」（substantial contributions）的评价；8 份简报背后的机构或个人与 Google 有赠款、应付款、近似结算收益（cypres settlement proceeds）或雇用关係；2 份简报实体与 Google 有明显商业往来；1 份由几名前美国政府雇员提交的简报，都曾在 Google 前高层经营的小型政府机构工作……这些团体涉及美国图书馆协会、EFF 和 Python 软体基金会，以及 83 名电脑科学家，包括前 Java 执行委员会成员 Doug Lea。
除了微软和 IBM，前 100 大科技公司的 98 家都没有提交任何简报。
这篇文章一出，原 Sun 员工、现任 Google 首席 Java 架构师 Joshua Bloch 坐不住了，在 Twitter 回击：抹黑对 java 贡献巨大的 Doug Lea 是无用的，他 14 年前接受 Google 一笔小额捐款，但立即分给参与 Java 程式测试的优秀本科生。甲骨文，你不感到羞耻吗？
开发者虽然并不一定都认同 Google 说法，但对甲骨文的态度都一致：强烈反对。
一位开发者表示，甲骨文似乎忘记或不知道简报提交者不一定要公正。事实上，简报是否被接受取决于提交者是否有合理理由。一些辩护状纯粹只有学术性，是在告诉法庭将如何受判决影响。」
大部分人都认为複製 API 的说法很荒谬，如果甲骨文赢了，软体互动方式将永远改变。「甲骨文或许会收到大笔版权费，透过剥削其他开发者和公司」，但长远来说，对 Java 的应用和生态也会造成影响：
Larry 摧毁了大家对 Java 这开放平台的信任。
如果说有人在损害 Java 的利益，那就是甲骨文。这场诉讼后，人们选择 Java 前都会三思而行。API 版权保护将是 IP 历史的新低点。
2010 年这场诉讼之前，API 不受版权保护是业界潜规则。若甲骨文胜利，将会开启潘朵拉的盒子。也许法院最终裁定 API 版权延伸到程式设计语言的核心特徴，或会找到法条区分普通 API 和程式设计语言版权。但不管怎样，不确定性很大。灰色地带要明确，需数年官司和数百万美元的法律费用。
Google 有两种可能胜诉的方式，第一是大多数人期待的，法院裁定 API 无法获得版权；第二，最高法院认为 API 版权要具体问题具体分析，而 Google 的複製属于合理使用範围。这虽能使 Google 免于开给甲骨文 10 位数美元支票，但仍可能将软体业拖入泥潭。
合理使用，是多幺见仁见智的主观标準啊。检举这种行为可能会增加，但大多数公司并没有 Google 的身家和法律资源打官司，所以未来难乐观。
- Before it sued Google for copying from Java, Oracle got rich copying IBM’s SQL
