最近一桩缠绵十年的案子，因为临审将近，又被大家翻出来。那就是甲骨文和谷歌 API 侵权之争。
雷锋网(公众号：雷锋网)AI源创评论了解到，这桩案子起源于 2009 年，甲骨文斥资 74 亿美元收购发明了 Java 的 Sun Microsystems。次年甲骨文提起了对谷歌的诉讼，理由是 Android 非法复制了 11000 行代码，侵害了 Java 版权专利。
谷歌自然是不肯的。于是过去十年，两大公司从美国旧金山联邦法院，辩论到联邦巡回上诉法院，再到最高法院，双方轮流不服，轮流上诉。
从谷歌视角来说，经历了一审胜诉、二审败诉、最高法院拒绝审理、再审胜诉、再再审败诉。最新的消息是，最高法院计划在 3 月 24 日左右再审。
这场诉讼在网络、媒体上也是讨论得沸反盈天。近日，外媒 arstechnica 报道指出，甲骨文的发家史其实就是一部抄袭史，通过抄袭 IBM 的 SQL 发了财。甲骨文发言人回应，绝无此事。
那么，这其中到底有什么样的故事？
十年诉讼，轮流上诉这一场史诗级的版权诉讼，不仅是因为诉讼双方耗费了漫长时间和经历——过去有几桩类似的版权案件都不了了之，可能会让谷歌损失数十亿美元，并且，这桩案件将对整个软件行业产生巨大影响，谷歌提醒美国最高法院称，甲骨文有可能成为垄断势力。
先简单回顾一下诉讼历史：
2010 年，甲骨文起诉谷歌侵犯了 7 件与 Java 相关的专利和版权，要求谷歌赔偿约数十亿美元的损失。
2012 年 5 月，美国旧金山联邦法院（或称加州北区法院）的法官裁定，Java API 不受版权保护，任何人都可以免费使用；10 月，甲骨文上诉。
2014 年，美国联邦巡回上诉法院推翻了一审部分结论，称必须尊重软件的版权保护。
谷歌上诉，2015 年 6 月，美国最高法院拒绝就受理谷歌上诉。起诉讼重返旧金山联邦法院，由该院就谷歌另外提出的“合理使用”的观点进行庭审。
2016 年 5 月，旧金山联邦法院复审，判决谷歌公司的行为合理，免付版权赔偿。
甲骨文上诉，2018 年 3 月，上诉法院再次裁决谷歌侵权，甲骨文索要 88 亿美元赔偿。
2019 年 11 月，在 78 名计算机科学家的陈情下，美国高院受理了谷歌的上诉，将对此前裁决复审。
你或许也注意到，旧金山联邦法院和上诉法院在十年内分别坚定支持谷歌、甲骨文，是这场拉锯战这么持久的原因。
甲骨文的诉讼点不是谷歌抄袭了 Java 语言，而是使用过线，在没协议的情况下抄袭了版权属于甲骨文的 37 个 JavaAPI 段。所以这场漫长的诉讼焦点在于，API 是否也受版权法的保护，或者说在多大程度上获得版权保护。
谷歌特别理直气壮地表示，它没有做错任何事情，因为版权法的版权保护并不包括“系统”和“操作方法”。谷歌认为，它复制的 Java 方面——函数名、参数类型等等——完全符合这些例外，版权的合理使用原则允许这种复制。根据加州联邦法院的记录，谷歌从 Java API 中复制了 37 个包、616 个对象类和 6088 个函数。
计算机软件的保护边界一直是一个很难判定的问题。起初多数国家并不赞成版权法保护程序，美国是最早的推动者，在它强大的政治与经济压力下，各国逐步接受了程序应当作为作品受到保护的要求。计算机程序分为源程序和目标程序。API 介于源程序和目标程序之间。
关于 API 应不应该受保护，网友 @ozzee 表示，“就像你不能给字典版权一样，你也不能给 API 版权。如果我拥有所有英语单词的版权，而且我要求你必须使用我的纸张、空气和设备来说出这些单词，你会怎么想？给了 API 版权，一个开发者就会被 API 供应商所束缚。”
软件业都很关注这起诉讼，不少公司都是站在谷歌这边。微软、IBM 曾警告称，甲骨文的做法可能会给行业带来混乱。如果拷贝是侵权行为，不仅会给许多软件公司带来法律上的麻烦，还会对客户不利。APIs 广泛存在于软件业，这使得相互竞争软件产品也可以互操作，这意味着客户的转换成本更低，软件初创企业进入门槛也更低，因为如果一个新产品与客户已经知道和使用的软件产品是兼容，就更容易销售。
今年 1 月份，谷歌提交了一份名为“friend of the court”的法律文件简报，其中 Mozilla，Medium，Cloudera，Reddit 等公司都一起呼吁联邦法院应该允许 API 继续不受版权保护，或者说合理使用。
甲骨文其身不正？而在起诉谷歌抄袭 Java 之前，甲骨文或许还要先收拾下黑历史。外媒 arstechnica 报道称，甲骨文的发家史其实就是一部抄袭史，通过抄袭 IBM 的 SQL 发了财。如果属实，这些历史与它现在 API 版权问题上的立场无疑是矛盾的，不利于胜诉。
软件公司一直在复制他们竞争对手 APIs。如果有人应该理解这种复制的重要性，那必然有甲骨文。甲骨文在 20 世纪 70 年代开始销售的第一款产品就是，基于当时新的 SQL 的数据库。而 SQL 是由 IBM 发明的，甲骨文似乎没有获得使用它的许可。
讽刺的是，如果甲骨文赢了这场法律战，也就是扼杀了 40 年前的自己，未来的初创企业将无法像甲骨文 40 年前那样——产品能与一个成熟的竞争对手兼容，将互操作性作为卖点。
arstechnica 认为，甲骨文对 SQL 的复制与谷歌对 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 内部使用。直到 20 世纪 80 年代初，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 许可，相关人员似乎都认为甲骨文不需要许可。
