2007 年，Google 开放了 Android 的核心代码，开源的这部分称之为 Android 开源项目 （Android Open Source Project，简称 AOSP）。跟 Google 内部开发的 Android 有些不一样，它缺少了设备驱动程序以及谷歌移动服务（ Google Mobile Services，简称 GMS）等闭源组件。不过，它仍然可以编译出可用的系统。

 AOSP 的开源引起了争议，争议的焦点是它所采用的许可证。

 众所周知， AOSP 是基于 Linux 内核开发的一款操作系统。Linux 内核的许可证是强 Copyleft 的 GPLv2，它规定任何衍生版本都要在 GPLv2 下分发，但 AOSP 却采用了 Apache-2.0。

 这是否意味着， AOSP 违背了 GPLv2?

 关键的 HAL 层

事实上，说 AOSP 采用 Apache-2.0 并不准确。

与其说 AOSP 是一个操作系统，不如说是一个包含了 Linux 内核，以及类库、应用框架等组件的软件集合体。 Linux 内核单独分为一组，称之为 Kernel Space，采用 GPLv2 ；而运行在 Linux 之上的其他组件称之为 User Space，采用 Apache-2.0、BSD、MIT 这样的宽松型许可证。

 为什么会这样呢？

 本来，驱动程序应该放在 Linux 内核里面。因为 Linux 是宏内核操作系统（Macrokernel），驱动存活在内核，与内核共生在相同的地址空间，运作效率高。

 但硬件厂商不乐意了，驱动程序包含了重要的硬件参数，放在内核里面就必须根据 GPLv2 开源，核心商业机密就泄露了。

 为了打消硬件厂商的顾虑， Google 就搞了一个中间层 ——硬件抽象层（Hardware Abstract Layer，简称 HAL ），把驱动的主要业务逻辑从内核中剥离出来，放在 HAL 层，通过接口调用内核系统。

 HAL 层属于 User Space，根据 Apache-2.0，硬件厂商可以自由选择将驱动程序开源或者闭源，不愿开源的可以只提供二进制代码。内核中也有少部分驱动代码，不过只有控制命令和数据的功能，开源了也无所谓。

Android 软件堆栈。 

除了规避 GPL 之外， HAL 层还有一大优势。它为移动领域五花八门、标准不统一的硬件驱动定义标准接口，避免 Android 过分依赖 Linux 内核，后续的扩展和整机集成变得更加高效，满足了手机制造商的重要诉求。

难道真的跟 Google 所想的一样，调用内核系统的 HAL 层，不需要遵循 GPLv2 吗？

按照“Linux 之父” Linus 的说法，确实如此。1993 年，Linus 及其他开发者在 Linux 内核源码树的 COPYING 文档中，添加了对许可限制和范围的说明。他们认为，用户程序通过正常系统调用内核服务，是对内核的正常使用，不属于派生作品，不受 GPL 约束。该说明一直沿用至今。

 通过隔离地址空间方式，避免被 GPL“传染”，被认为是一种有效的方式。 

GPLv2 的维护者——自由软件基金会（Free Software Foundation，简称 FSF ）认为，软件聚合体包含有多个独立的程序，并在同一个 CD-ROM 或其他媒体上发行。如果两个模块在同一个可执行文件中，那它们肯定会绑定在同一个程序中，成为一个整体。如果两个模块在共享地址空间中，链接在一起运行，那意味着它们肯定会组合成一个程序。毫无疑问，FSF 所说的这两种情况，只要其中一个模块是 GPL，另一个都会被“传染”。 

反过来，pipes、sockets 和命令行参数通常都是两个不同程序通信的机制。因此，如果使用它们来通信，这些模块正常应该是独立的程序。不过 FSF 也提到了例外情况，如果通信的语义非常密切，交换复杂的内部数据结构，那么它们也被会认为是一个大程序的两个组合部分。 

因此，像 Google 这样创建 HAL 层，让驱动程序与 Linux 内核在分开的地址空间内运行的方式，是可以避免被“传染”的。 

漩涡中的 Bionic

Android 真的可以完全脱离 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行以上。

正如事实所呈现的那样，批评谷歌的大多是法律相关人士，而站在 Google 这一边的，几乎都是开发者。 

关于 AOSP 是否违背 GPL 的争论早已在十年前结束。当时，Google 为 AOSP 选择 Apache-2.0 等宽松型许可证的做法，被认为不够开放，令很多人看衰 AOSP 以及 Android 的未来。现在来看，这些人做出了错误的判断，今天，基于 AOSP 开发的 Android 系统已经成为用户量最多的移动端操作系统。 

而关于 API 是否受版权保护的问题，在 2021 年 4 月 5 日已经有了答案。那天，拉锯了十年的“Oracle 诉 Google 侵犯 Java 版权”案迎来了美国最高法院的最终裁定：Google 对 Java API 的使用被归为“合理使用”，没有违反联邦版权法 —— 而非 Oracle 认为的“纯属剽窃”。