Google|AOSP 违背了 GPLv2?( 二 ) Linux|安卓|软件|操作系统

反过来， pipes、sockets 和命令行参数通常都是两个不同程序通信的机制。因此，如果使用它们来通信，这些模块正常应该是独立的程序。不过FSF 也提到了例外情况，如果通信的语义非常密切，交换复杂的内部数据结构，那么它们也被会认为是一个大程序的两个组合部分。
因此，像 Google 这样创建 HAL 层，让驱动程序与 Linux 内核在分开的地址空间内运行的方式，是可以避免被“传染”的。
漩涡中的 BionicAndroid 真的可以完全脱离 Linux 内核吗？如果可以的话， Google 就不会再次陷入“违背 GPL”的风波之中。
为了让 User Space 与内核进行有效交互， Google 创建了 Bionic 。它是一个 C 标准库，是 Android 最为底层的 API ，用来替代当时流行的 GNU C 库（glibc）。glibc 基于 Copyleft 性质的 LGPL 许可分发，如果 User Space 中的软件静态链接至 glibc，也会“感染”LGPL。
但是另一个麻烦又来了。 Bionic 使用了 Linux 内核中的头文件。为了摆脱 GPLv2 ， Google 利用自动程序删除了头文件中源代码注释和其他一些元素，并以 BSD 许可证进行分发。
Google 在 Bionic 中的每个头文件开头进行了说明：“该头文件是从一个同名的 Linux 内核头文件自动生成的，以使 User Space 调用内核所需的信息对 libc 可用。它只包含从原始头文件生成的常量、结构和宏，因此，没有包含受版权保护的信息。 ”
这些信息在2008 年谷歌 I/O大会上公开，但直到三年后才发酵。当时正值 Oracle 对 Google 提起诉讼，认为它侵犯 Java 版权，并且获得了法院支持。落败者 Google 引来了众多批评的声音，旧事重提， Bionic 陷入了争议的漩涡。
打响质疑 Google 第一枪的人，是休斯顿大学法律中心的法学教授 Raymond Nimmer 。他在文章中表示， Linux 内核的头文件涉及大量受版权保护的文本和代码， Google 可以删除部分注释和代码，但很难删除头文件结构中涉及的表达式，因为它要保持头文件的有效性。表达式是设计者经过组织术语和代码的方式，这正是头文件受版权保护的原因。
知识产权诉讼律师 Edward Naughton 在《赫芬顿邮报》上发表了看法。他认为 Google 简单地“清理”受版权保护信息，这是对软件和源代码版权保护的大胆攻击。受版权保护的部分可能无法完全删除， Bionic 中的头文件很可能仍受 GPLv2 的约束。
开源知识产权专家Florian Muller也站在了 Naughton 的一边。他说谷歌的行为是错误的，头文件中可能存在受版权保护的元素，比如内联函数。甚至还可能出现这种情况：把一些不受版权保护的个体元素组合成一个整体，从而受到版权保护。
并且他还指出，如果删除源码注释以及某些功能就能规避 GPL ，那么这将导致 Linux 和其他 GPL 软件分叉出专有版本。这种简化 GPL 的行为很是荒谬。
对于 Bionic 中的头文件问题， Linus 是怎么看待的？Brian Proffitt 曾经就 Naughton 发表的文章联系了 Linus。他认为Android违反 GPL 是伪命题， “我们一直很清楚，内核系统以任何方式调用接口，都不会产生 GPL 的衍生品。 ”不过，当时他对 Bionic 引用 Linux 内核头文件代码的事情并不了解。
这不是第一次因为头文件的问题导致此类风波了。 2003 年， SCO Group 公司声称 Linux 窃取了 Unix 知识产权。 OSI 创始人 Eric Raymond 的看法是，头文件中有些代码看起来很相似是有充分理由的， “它们几乎是 POSIX 和其他技术标准强制执行的所有宏和声明” ，但没有任何可执行代码。这是不可避免的。
此前， FSF 曾讨论过这一问题。 Richard Stallman 在邮件中说：“仅仅使用结构定义、类型定义、枚举常量、具有简单主体的宏等，还不足以进行衍生工作。要做到这一点，需要大量代码（来自内联函数或具有实体的宏）。 ”结合GPLv3 中第 3 条， “大量”可能是指代码量在10行以上。