美最高法院将对甲骨文诉谷歌Android代码案作出终审裁定

（图 via ExtremeTech）

据悉，当谷歌最初开发 Android 移动操作系统时，便决定与 Java 实现兼容。作为对比，苹果 iOS 那边使用了面向对象的 Objective-C 代码方案。

显然，搜索巨头希望借助强大且流行的社区的力量，让 Android 与流行的 Java 编程语言实现互操作，进而获得更大的竞争力。

为了做到这一点，该公司重构了几个 Java API，其中就包括卷入法律纠纷的 37 个。

对于从 Sun 那里接过了 Java 的甲骨文，是否有资格从 Android 身上咬下价值数十亿美元的一块肥肉、以及谷歌的语言兼容性是否涉及侵权，就成为了双方争论的两大焦点。

经历 10 年的时间，两家公司的高管都已经发生了较大的变动。当谷歌于 2010 年作出应对时，涉及的还是 7 大专利和 1 大版权主张。

但到 2012 年的时候，争议点已经缩减到了仅由大约 11500 行代码组成的 37 个 Java API 。相比之下，各大 Android 版本的总代码量在 120~140 亿行之间。

据说争议代码源于单独的逆向工程（所谓的 Clean Room）项目，当谷歌与 Sun Microsystems 谈崩之后，此事的重要性就变得不言而喻。

即便甲骨文是在 2010 年初才收购的 Sun，但它还是在当年 8 月就向谷歌发起了法律诉讼。

至于这里提到的应用程序编程接口（API），特指软件编程中明确定义的交互集合，旨在提供各种定义库和其它功能的快速访问。

对于需要被经常调用的冗长代码来说，API 能够极大地解放程序员的工作量，让他们无需重复发明轮子，即可特定基础上构建代码。

从技术上来说，谷歌能够在 Java 编程上多花点力气，以避开卷入争议的这 37 个 Java API 软件包。

然而这些基础的软件包，已经涵盖了 java.lang 和 java.util，可为数学运算或日期 / 时间等功能提供支持。

问题在于，谷歌通过 Clean Room 项目重构了这 37 组 Java API 。甲骨文方面并未断言该公司照搬全抄，而是指责其“结构、顺序和组织”是如此相似，以致于侵犯了该公司的版权。

无论这些 API 中的封包、类型和方法，都被命名成了相同的名称。通过标准 Java 编写的代码不一定可以在 Android 上运行，但两者的情况是相当接近的。

本文素材来自互联网