上周五, Florian Mueller 在 Android 源代码树 http://android.git.kernel.org/ 上发现两套文件可能会有损 Google 的名声,并且会令 Google 在与 Oracle 之间的法律诉讼之战中处于不利地位。
目前已经有很多人对 Florian Mueller 的发现 做出了回应。关键点主要在于对源代码树的两个独立的调查结果。
- 包含了多媒体 API MMAPI.zip,它可以免费下载但却不能再次分发。
- 其他一些可能经过了反向工程的文件,估计是使用了 Java 反编译器(非常类似于之前的 PolicyNodeImpl 问题)。
值得强调的是这些文件并没有随 Android 内核一同发布;他们是测试源代码树的一部分,因此不会出现在最终的产品当中。这样就会限制 Oracle 的赔偿要求。
MMAPI 包含在面向 Java ME 的 SONiVOX 当中,其文档指出 MMAPI 是不可以再次分发的。但却错误地放到了源代码树中;毫无疑问,律师们会提出这样的质疑:包含在公开可读的源代码仓库中是否可以认为是重新发布呢?假如源代码树并不是公开可读的,那么就不会破坏许可条款。值得注意的是,从来没有人在 Apache License 下重新声明这些代码的许可。
然后就是反编译或重新生成的文件了。虽然 Sun 的源代码拥有明确的许可条款(包含可能的 GPL 文件),但这却不适用于反编译文件。当反编译代码时(比如使用 JAD 工具),生成的源代码属于运行反编译工具的人。使用反编译工具所生成的源文件无需遵守被反编译的代码所遵守的许可。对于 Java 来说这很容易就能实现,因为 Java 字节码文件中包含了足够的信息,这样编译后的代码与源代码的相似度非常高,哪怕无法获取到源代码也没问题。
当然了,现在并没有证据表明这些源代码是通过反编译工具生成的;这只不过是个假设而已。需要显式常量或是“魔力值”的很多 API 都是 API 契约的一部分,这些常量或数值并不只是随意添加到代码中的(这里的意思指的是很多 API 中都拥有一些常量或是数值,他们是 API 契约所要求的,因此根据反编译后的结果很难推测出这些常量或数值所代表的含义——译者注)。软件的反向工程有时用于在不同的版权下创建代码(虽然通常我们需要整洁的设计而非直接的反编译)。但这么做却无法回避专利问题,因此与这些侵犯了专利的测试代码相关的内容依然是个问题。
这还涉及到了与分布式版本控制系统如Git 相关的一个潜在问题。虽然代码已经从目前的树头(head of tree)中移除了,但还是可以通过检出之前的分支访问到他们。即便无法访问这些分支,但只要对仓库进行克隆就可以获得这些代码。Git 在这方面要比Hg 更加灵活,因为Git 拥有git --filter-branch 选项,可以重写历史以删除代码的所有访问痕迹,但Android 却没这么做。之所以这样是因为这会改变所有提交的标识符并且会对那些希望参与开发的人员产生不良影响;但对于检测不属于仓库中的代码这种情况应该是必要的。
既然有疑问的代码并没有随Android 操作系统一同发布而只是测试代码(已经从主分支中移除了),Google 就可以放心地说在发现后就已经移除了不恰当的代码,这并不会产生多大的版权问题。这并不会对Oracle 与Google 之间的法律诉讼之战造成多少影响, Groklaw 对此做过详尽的介绍。
评论