最近一桩缠绵十年的案子，因为临审将近，又被大家翻出来。那就是甲骨文和谷歌API侵权之争。

　　雷锋网(公众号：雷锋网)AI源创评论了解到，这桩案子起源于2009年，甲骨文斥资74亿美元收购发明了Java的SunMicrosystems。次年甲骨文提起了对谷歌的诉讼，理由是Android非法复制了11000行代码，侵害了Java版权专利。

　　谷歌自然是不肯的。于是过去十年，两大公司从美国旧金山联邦法院，辩论到联邦巡回上诉法院，再到最高法院，双方轮流不服，轮流上诉。

　　从谷歌视角来说，经历了一审胜诉、二审败诉、最高法院拒绝审理、再审胜诉、再再审败诉。最新的消息是，最高法院计划在3月24日左右再审。

　　这场诉讼在网络、媒体上也是讨论得沸反盈天。近日，外媒arstechnica报道指出，甲骨文的发家史其实就是一部抄袭史，通过抄袭IBM的SQL发了财。甲骨文发言人回应，绝无此事。

　　那么，这其中到底有什么样的故事？

　　十年诉讼，轮流上诉

　　这一场史诗级的版权诉讼，不仅是因为诉讼双方耗费了漫长时间和经历——过去有几桩类似的版权案件都不了了之，可能会让谷歌损失数十亿美元，并且，这桩案件将对整个软件行业产生巨大影响，谷歌提醒美国最高法院称，甲骨文有可能成为垄断势力。

　　先简单回顾一下诉讼历史：

　　2010年，甲骨文起诉谷歌侵犯了7件与Java相关的专利和版权，要求谷歌赔偿约数十亿美元的损失。

　　2012年5月，美国旧金山联邦法院（或称加州北区法院）的法官裁定，JavaAPI不受版权保护，任何人都可以免费使用；10月，甲骨文上诉。

　　2014年，美国联邦巡回上诉法院推翻了一审部分结论，称必须尊重软件的版权保护。

　　谷歌上诉，2015年6月，美国最高法院拒绝就受理谷歌上诉。起诉讼重返旧金山联邦法院，由该院就谷歌另外提出的“合理使用”的观点进行庭审。

　　2016年5月，旧金山联邦法院复审，判决谷歌公司的行为合理，免付版权赔偿。

　　甲骨文上诉，2018年3月，上诉法院再次裁决谷歌侵权，甲骨文索要88亿美元赔偿。

　　2019年11月，在78名计算机科学家的陈情下，美国高院受理了谷歌的上诉，将对此前裁决复审。

　　你或许也注意到，旧金山联邦法院和上诉法院在十年内分别坚定支持谷歌、甲骨文，是这场拉锯战这么持久的原因。

　　甲骨文的诉讼点不是谷歌抄袭了Java语言，而是使用过线，在没协议的情况下抄袭了版权属于甲骨文的37个JavaAPI段。所以这场漫长的诉讼焦点在于，API是否也受版权法的保护，或者说在多大程度上获得版权保护。

　　谷歌特别理直气壮地表示，它没有做错任何事情，因为版权法的版权保护并不包括“系统”和“操作方法”。谷歌认为，它复制的Java方面——函数名、参数类型等等——完全符合这些例外，版权的合理使用原则允许这种复制。根据加州联邦法院的记录，谷歌从JavaAPI中复制了37个包、616个对象类和6088个函数。

　　计算机软件的保护边界一直是一个很难判定的问题。起初多数国家并不赞成版权法保护程序，美国是最早的推动者，在它强大的政治与经济压力下，各国逐步接受了程序应当作为作品受到保护的要求。计算机程序分为源程序和目标程序。API介于源程序和目标程序之间。

　　关于API应不应该受保护，网友@ozzee表示，“就像你不能给字典版权一样，你也不能给API版权。如果我拥有所有英语单词的版权，而且我要求你必须使用我的纸张、空气和设备来说出这些单词，你会怎么想？给了API版权，一个开发者就会被API供应商所束缚。”

　　软件业都很关注这起诉讼，不少公司都是站在谷歌这边。微软、IBM曾警告称，甲骨文的做法可能会给行业带来混乱。如果拷贝是侵权行为，不仅会给许多软件公司带来法律上的麻烦，还会对客户不利。APIs广泛存在于软件业，这使得相互竞争软件产品也可以互操作，这意味着客户的转换成本更低，软件初创企业进入门槛也更低，因为如果一个新产品与客户已经知道和使用的软件产品是兼容，就更容易销售。

　　今年1月份，谷歌提交了一份名为“friendofthecourt”的法律文件简报，其中Mozilla，Medium，Cloudera，Reddit等公司都一起呼吁联邦法院应该允许API继续不受版权保护，或者说合理使用。

　　甲骨文其身不正？

　　而在起诉谷歌抄袭Java之前，甲骨文或许还要先收拾下黑历史。外媒arstechnica报道称，甲骨文的发家史其实就是一部抄袭史，通过抄袭IBM的SQL发了财。如果属实，这些历史与它现在API版权问题上的立场无疑是矛盾的，不利于胜诉。

　　软件公司一直在复制他们竞争对手APIs。如果有人应该理解这种复制的重要性，那必然有甲骨文。甲骨文在20世纪70年代开始销售的第一款产品就是，基于当时新的SQL的数据库。而SQL是由IBM发明的，甲骨文似乎没有获得使用它的许可。

　　讽刺的是，如果甲骨文赢了这场法律战，也就是扼杀了40年前的自己，未来的初创企业将无法像甲骨文40年前那样——产品能与一个成熟的竞争对手兼容，将互操作性作为卖点。

　　arstechnica认为，甲骨文对SQL的复制与谷歌对Java的复制非常相似。为什么这么说？

　　SQL的语言看起来是这样的："selectcustomer_name,ship_datefromorderswhereproduct_id=17andstate='CA'."。

　　从上可知，第一，SQL有一个简单的、类似英语的语法。没有编程或数据库管理背景的人可以通过阅读这个语句大致了解它的作用。第二，SQL是一个申诉式编程语言（DeclarativeLanguage）：用户指定他们在寻找什么信息，但是他们让数据库系统来决定如何找到这些信息。也就是说，SQL是一个对非程序员都很友好的语言，稍加练习，就可以编写SQL查询来完成一系列任务。

　　1974年，一小群IBM研究人员在一个叫做SystemR的软件包中实现这些想法。与此同时，IBM的研究人员发表了描述工作的研究论文。这些出版物非常详细，包括完整的SQL语言规范。SystemR做出来了，但在接下来的几年就只是在IBM内部使用。直到20世纪80年代初，IBM才对外提供了一个基于SQL的商业数据库。

　　LarryEllison

　　而大约在1977年，LarryEllison和他的联合创始人发现了SQL语言，他们当时开了一家名为SoftwareDevelopmentLaboratories的软件咨询公司，然后想转型到数据库销售公司。LarryEllison意识到，如果甲骨文数据库能与IBM的SQL标准完全兼容，可信度会更高。

　　SQL的设计者DonaldChamberlin在1995年接受过一个采访，其中提到，LarryEllison在1978年打电话给过他，想了解更多IBM研发SQL的细节，包括错误代码值。Chamberlin本人是很乐意分享的，但是他的老板拒绝了这件事，表示错误代码是保密的。

　　不过因为IBM的白皮书展示了足够的细节，足以克隆IBM的数据库技术，甲骨文在1979年发布了第一个版本的数据库。其时，该公司反复宣扬该产品起源于IBM。“甲骨文的用户界面就是SQL”一位早期的甲骨文宣传员说。

　　因为比IBM提前两年上市，甲骨文一下声名大噪，并在未来几年保持着SQL数据库领导者的地位。

　　后来SystemR内部还讨论过IBM公布SQL的细节是否是一个错误，这让甲骨文吃掉了许多应该属于IBM的市场份额。但也有内部人士认为，发表研究论文之后，才让IBM意识到这项技术很重要，所以从一开始就很认真对待。

　　“如果我们没有发表那些论文，它就会失败，”1995年，IBM的老员工MikeBlasgen说。“IBM很有可能会忽略它。”

　　一直以来，甲骨文似乎都没有试图从IBM那里获得SQL许可，相关人员似乎都认为甲骨文不需要许可。

　　谷歌与Java过往

　　而谷歌，不管怎么说曾经试图与Sun建立授权关系。2005年8月，谷歌低调收购安卓，开始研发手机操作系统，同年谷歌找过SunMicrosystems讨论过许可协议，并达成了一个暂时协议——谷歌向Sun支付2800万美元（一说是4000万美元），获得与Java相关的专利、Java商标和其他资产的使用授权。另外，谷歌坚称，他们从未试图获得Java界面的版权，在他们看来，法律对此并没有要求。

　　但是协议很快破裂，谷歌后来称主要原因不是价格，而是Sun对安卓平台发展的控制力度超出了谷歌的意愿。因此，谷歌决定在没有Sun许可的情况下构建自己的Java版本。

　　这意味着谷歌要从Java语言的功能规范开始，也就是Java语言的规则，包括关键字、语法以及标准函数的名称和参数类型。谷歌没有像甲骨文复制SQL一样复制这些功能的代码，工程师们而是从头开始编写自己的代码，并产生了与Sun的Java代码相同的结果。

　　谷歌后来宣布安卓是基于Java语言时，Sun公司的首席执行官JonathanSchwartz当时还挺高兴的，他公开表示，“我只是想和其他同事一起衷心祝贺谷歌推出的新Java/Linux手机平台安卓。”

　　可能是力量悬殊，总之Sun当时并没有找谷歌的麻烦，而2009年该公司被甲骨文收购后，就立马转了做法。2010年1月，Sun交易结束，不久甲骨文就起诉了谷歌。值得关注的一点是，当年1月后，多位前Sun高管从甲骨文离职，其中包括前Sun首席执行官JonathanSchwartz、XML发明人TimBray、前SunCTOJamesGosling，其中TimBray加入了谷歌安卓开发团队。

　　对比谷歌和IBM的复制，有一个挺大的差别：谷歌复制了Sun已经问世的产品，甲骨文复制了一个IBM尚未发布的产品，学的是IBM发布白皮书。

　　CornellTech法学教授JamesGrimmelmann在今年1月接受采访时表示，从版权角度来看，两者没有太大差别。如果复制API是侵犯版权的，那么从文档中复制API也是侵犯版权的。根据版权法，IBM的论文是“受保护的作品”。"如果SQL规范是有版权的，那么无论是从软件还是白皮书中复制的，版权都适用。

　　甲骨文一直以来的起诉点是谷歌抄袭了甲骨文的API。可能在他们的视角中，自己对SQL的复制与谷歌对Java的复制是不同的。

　　雷锋网AI源创评论了解到，事实上，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年的安卓7.0，谷歌舍弃了私有的SunJDK而转用开源的OpenJDK；2017年I/O大会上，谷歌宣布Kotlin取代Java成为Android一级开发语言。两年后，谷歌表示，超过50%的专业Android开发人员现在使用该语言开发他们的应用程序，在最新的StackOverflow开发人员调查中，它被列为第四大最受欢迎的编程语言。

　　一边倒地批判甲骨文

　　对于外界关于其抄袭SQL的言论，甲骨文并不认可，该司称，“把苹果和花椰菜放在一起比较，完全脱离事实，这是一个不正确的假设。”

　　这还没完，执行副总裁KenGlueck在官网发布了一篇题为《别理会躲在幕后的人》的博客，言辞犀利，炮轰谷歌和它的支持者，“伪装出一种获得大规模支持的现象，但背后可能不过是利益交易。”

　　“这不是关于创新的案件，而是盗窃。”Glueck表示，在软件行业，窃取其他开发人员的软件代码并不常见，而一些复制的行为也是版权者出于双方利益，一起合作，Java并不是拒绝选择，而是授权许可在版权方手里。

　　“谷歌试图寻求外部团体的支持，拉上其他公司登上friendofthecourt简报，制造案件有重大意义和争议、大众甲骨文的诉求阻碍着创新的印象。”

　　另外，他还提到谷歌递交的26份简报，其中7份简报的实体有从从谷歌获得“实质性贡献（substantialcontributions）”的评价；8份简报背后的机构或个人与谷歌之间有着赠款、应付款、近似结算收益（cypressettlementproceeds）或雇用关系；2份简报实体与谷歌之间有明显商业往来；1份由几名前美国政府雇员提交的简报，这些人都曾在一家由谷歌前高管经营的小型政府机构工作过……这些团体涉及美国图书馆协会、EFF和Python软件基金会，以及83名计算机科学家，包括前Java执行委员会成员DougLea。

　　“除了微软和IBM，前100家科技公司中的其他98家公司可都没有提交任何一份简报。”

　　这篇文章一出，原Sun员工、现谷歌首席Java架构师JoshuaBloch坐不住了，在推特上回怼：给对java贡献巨大的DougLea泼脏水是无用的，他是14年前接受了谷歌的一笔小额赠款，但立即分给了那些参与Java程序测试的优秀本科生。“甲骨文，你不感到羞耻吗？”

　　另外雷锋网AI源创评论注意到，开发者中虽然并不一定认同谷歌的说法，但面对甲骨文的态度基本是一致的——强烈反对。

　　一位开发者表示，甲骨文似乎是忘记或不知道简报的提交者并非一定要公正。事实上，简报是否被接受取决于提交者是否给出了合理的理由。一些辩护状纯粹是学术性的，他们是在告诉法庭他们将如何受到判决的影响。”

　　大部分人都认为拷贝API的说法是荒谬的，如果甲骨文赢了，软件交互方式将会被永远改变，“甲骨文或许会一时收获大笔版权费，通过剥削其他开发者和公司的方式”，但是长远来说，对于java的应用和生态也会造成影响：

　　“Larry摧毁了大家对于Java作为一个开放平台的信任。”

　　“如果说有人在损害Java的利益，那就是甲骨文。在这场诉讼后，人们在选择Java之前会三思而行。API版权保护将是IP历史上的一个新低点。”

　　在2010年这场诉讼之前，API不受版权保护是行业潜规则。但若甲骨文胜利，将会打开潘多拉魔盒。也许法院最终会裁定API版权延伸到编程语言的核心特性，或者他们会找到一个法律来区分普通的API和编程语言版权。但不管怎样，不确定性很大。灰色地带要明晰，需要数年的诉讼和数百万美元的法律费用。

　　谷歌有两种可能胜诉的方式，第一是绝大多数人所期待的，法院裁定API不能获得版权。第二，最高法院可以认为API版权要具体问题具体分析，而谷歌的复制属于合理使用范围内。这虽能使谷歌免于写给甲骨文10位数的支票，但仍可能将软件行业拖入法律泥潭。

　　合理使用，是多么见仁见智的主观标准啊。举报这种行为可能会增多，而大多公司并没有谷歌的积淀和法律资源去耗官司，所以未来不容乐观。