Android在争议中逃离Linux内核的GPL约束【转】

为这个题材起名，我思考了许久，GPL 是著名的开放源代码许可协议，Linux 内核开源项目正是在 GPL 的庇佑之下，十多年来在服务器、PC 端以及各类嵌入式设备上成绩斐然，是当之无愧的当代计算机软件的基石，说 GPL 表明着 Linux 的开源精神，绝不为过。然而，现实世界中，GPL 开源乌托邦和商业社会的丛林法则之间存在剧烈的冲突，其中犬牙交错，艰难成长，从中引起的思考，与你们共享。

Linux 内核的 GPL 约束

总所周知，Linux 内核以 GNU 通用公共许可证第二版（GPL V2）的受权使用协议下发行。GNU 通用公共许可证是一种 “Copyleft” 形式的“版权”，保障任何人都可以对 Linux 内核以及其衍生产品的使用、修改和从新发布的权力，前题是不能修改发布条款。什么意思呢，任何 Linux 内核的衍生产品（Derived Work）必须遵循 GPL 协议进行发布。然而问题的核心在于什么是 Linux 内核的衍生产品，其中有几个致命问题，业界争论了十年有多。

一、使用 Linux 内核的头文件定义，进行系统调用的程序是否会被定性为衍生产品？

二、连接使用了其余 GPL 的类库的程序是否会被定性为衍生产品？

三、Linux 内核动态载入的模块 LKM（Loadable Kernel Modules）是否会被定性为衍生产品，以 LKM 形式开发的 Linux 驱动程序是否是衍生产品？

若是上述问题答案均为“是”，GPL 将为 Linux 打造一个的“封闭” 的开源世界，什么意思呢？一个 Linux GPL的操做系统核心运行在 “ 内核空间 ” ，上层的类库、框架、服务、应用运行在 “ 用户空间 ” 。用户空间上的任何服务不可避免的须要Linux 内核的头文件，进行系统调用，所以，中间层服务必须遵循 GPL 进行开放源代码。调用中间服务层的框架或者其余服务使用了 GPL 的类库，所以，也必须是 GPL 的。同理，上层应用也被 “ 传染 ” ，必须是 GPL 的。因而，从内核到驱动到中间服务到上层应用，造成了一个 GPL 一体化软件受权的软件发布总体。能够认为，这个总体上任何开发成果都是 GPL 的，除非极少数的例外程序可以证实自身独立于系统的GPL环境。这样的一个“软件闭包”排斥的商业化的软件模块以及“想要钱”普通开发者，将整个软件世界 划分为“ GPL 与 GPL 兼容的”的和非 GPL 的，每一个开发从业者面临着选择，要么 Linux+GPL ，要么 Linux 与你无关。

从新回到这三个问题，第一个问题，曾经被 Linux 内核的做者 Linus Torvalds 以及内核开发人员屡次澄清普通系统调用为非 GPL 的做用范围，甚至固化在 Linux 内核的源码 COPYING 文档中，为 Linux 用户空间的程序采用非 GPL 的受权许可证打下了基础。

第二个问题，具备明确的答案，是。这也是为什么 GPL 被抨击为具备“病毒感染”的特性，一旦程序使用了 GPL 的模块，自己即被传染，程序必须成为 GPL。若是主程序与 GPL 类库是静态连接（Static Link）的关系，业界通常认为主程序必须限定为 GPL。而对主程序动态连接（Dynamic Link）GPL类库主程序通常认为也必须是GPL的，若要打赢官司，必须证实主程序与GPL模块之间具备“独立性和可区分性”（Separate and Independent），才能逃离 GPL 的约束。GPL官方网站上的有这样的 FAQ：

If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license? (#IfLibraryIsGPL)

Yes, because the software as it is actually run includes the library.

 若是一个类库以 GPL 的许可证受权进行发布（不是 LGPL），是否意味着任何使用该类库的软件必须以 GPL 或者 GPL 兼容的许可证下进行发布？

是，由于软件包含了该类库才能运做。

第三个问题，是硬件厂商和 Linux 内核开发社区之间一场旷日持久的争论的中心。最著名的，莫过与图形显示设备厂商 AMD/ATI、NVidia 出自硬件规格保密以及知识产权的考虑，长期以二进制软件包的方式独立发布图形驱动，涉嫌违反了Linux内核开放源代码的软件受权协议 GPL，至今还是 Unity 与 Gnome 3 等依赖于硬件图形加速的新型桌面技术发展上的一大阴影。主要的 Linux 内核维护者 Greg Kroah-Hartman 曾经严厉的批判过，内核中的二进制软件包发布的模块是非法的、不道德的。

 

说 到此处，能够看到 GPL 下的 Linux，存在着开源精神和商业机密以及知识产权保护相关的商业精神存在尖锐对立，对硬件厂商以及其余商业软件开发者来讲，既不能忽视Linux广阔的 商业市场，也不能放弃产品规格以及知识产权保护，二者都会伤害其立命之本。在早年的一份嵌入式操做系统选型的研究报告指出，Linux 相对于其余的 BSD 的 Unix Like 操做系统，因为 GPL 的约束限制，不具备商业优点。（参见引用3）。一言以蔽之，业界有 GPL 的恐惧症。

然 而，在移动互联网蓬勃发展的今天，一个 Linux 的发布版本，Android 在各类智能嵌入式设备上面大放异彩。听说，Android 之父 Andy Rubin 极度厌恶 GPL（James Bottomley，Linux SCSI 子系统的维护者说其人“Working from an extreme dislike of the GPL”），然而 Android 向世人展现了采用 GPL 受权代码的手机也能得到巨大的市场成功。

Android：把 GPL 局限在内核空间

下图是 Openfoundry 绘 制的 Android 的受权许可证结构，能够看到在 Android 多层软件栈中，仅仅最核心的 Linux 内核使用了 GNU 通用公共许可证，在这个层次上，Google 对 Linux 内核的全部修改必须反馈回 Linux 主版本树（Android 的内核将在 Linux 3.3 版本进行回归，两个版本的 Linux 内核进行融合）。

其上层的类库以及应用框架以及所谓用户空间部分，大部分使用 了“ 温和 ”的 Apache-2.0 软件许可受权，容许 Android 上的开发商基于 Android 的源代码进行开发而不向社区反馈。基于上文讨论 GPL 的第一个问题，用户空间的类库以及程序使用 Linux 内核的系统调用不被视为是Linux内核的衍生产品，于是得以自由采用 Apache-2.0 的软件受权进行发布。GPL 世界和非GPL世界的分界线在于一个叫作 Bionic Libc 的类库。Bionic Libc 的关键之处在于若是 Bionic Libc 受到内核 GPL 的“感染”，将会波及非 GPL 的用户空间的各个模块。

Android 的 Bionic Libc 的类库，采用 BSD 的许可证受权。在 2008 年 Google IO大会上，一份著名的 PPT：“ Android Anatomy And Physiology ”讲到 Android 使用 Bionic Libc 类库替换Linux经常使用的 Gnu glibc ，其中一个主要缘由是 “ We want to keep GPL out of user-space ”。 （这其实有点难理解，毕竟 Gnu glibc 采用的是 LGPL 而非 GPL，并基于上文 GPL 第一点的讨论，使用系统调用的程序再也不被视为 Linux 内核的衍生产品，并不须要遵循 GPL，有兴趣者请看下文用户空间驱动部分的分析） 。Bionic Libc 充满着非议，Bionic Libc 拷贝内核头文件的行为，并在源码中声明的版权信息均遭到了 “ 侵犯 Linux 内核 GPL 约束 ” 的质疑。这是 Bionic 头文件的版权信息，许多人认为是非法的：

“This header was automatically generated from a Linux kernel header of the same name, to make information necessary for userspace to call into the kernel available to libc. It contains only constants, structures, and macros generated from the original header, and thus, contains no copyrightable information.”

头文件由Linux内核的同名头文件自动生成，用来获取完成用户空间系统调用的必要的信息。它只包含原头文件中的常数、结构和宏定义，所以，不包含版权信息。

无论如何，从目前的状况看，让 GPL 止步于内核空间的作法是成功的，并已经获得很大一部份内核开发者的认同。James Bottomley，Linux SCSI 子系统的维护者在 2011年 LinuxCon 大会日本站上谈到  Android 的商业成功与 GPL 恐惧的时候说：

We should also design more “bright line” systems which make the question of GPL compliance clear. The kernel’s user-space ABI is one such system; developers know that user-space code is not considered to be derived from the kernel. Making the boundary easy to understand helps to make the GPL less scary.

在遵照 GPL 的问题上，咱们必须澄清一些界线。内核的用户空间 ABI（应用二进制接口）就是一种 GPL 的做用边界，能让开发者意识到用户空间的代码，不被定性为内核的衍生产品，若是 GPL 的界线清晰而易懂，能够帮助你们消除对 GPL 的恐惧。

缓解 Linux 驱动的 GPL 困境

Android 的发展离不开硬件设备厂商的支持，硬件设备厂商最关注的是 Linux 驱动的 GPL 约束问题，公开驱动程序源代码将会泄漏设备的硬件规格和泄漏核心知识产权，这是硬件厂商 GPL 恐惧的原因。Google 竭尽全力的为硬件设备厂家排忧艰难，保驾护航。上文提到的 “ Android Anatomy And Physiology  ”，文中清晰的讲到 Android 在用户空间与内核空间之间存在着硬件抽象层  HAL（Hardware Abstraction Layer），HAL 类库本质上一种用户空间的驱动，其中的主要用途之一：规避 GPL。

用户空间的驱动

Linux 是单内核操做系统（Macrokernel），这种操做系统的一大特色是驱动存活在内核，优势是驱动与系统内核共生在相同的地址空间，运做的效率比较高， 缺点是当驱动有问题的时候，容易危及内核的工做安全。用户区间驱动的思路是将驱动的主要业务逻辑剥离出来放到用户空间的主驱动模块中，内核中的驱动是个 “影子”驱动，只有透传控制命令和数据的功能。

Android 的 HAL 至关于上图中的主驱动，其在内核中的驱动至关于上图中的影子驱动。规避 GPL 的硬件厂家把须要保护的商业机密以及知识产权相关的逻辑放在 HAL 层，以二进制包的方式发布，不须要公开源代码。

这种机制看上去很美，然而，一样面临着巨大的争议。HAL 类库与内核驱动之间经过普通的系统调用可以完成么？若是不是普通的系统调用，用户空间的驱动就违反了上文中的第一条，用户空间的驱动不能得到 GPL 例外的豁免。Edward J. Naughton 2011 年 3 月撰文认为，普通的系统调用应 被理解为 gnu glibc 向外暴露的系统调用接口，而 Android 经过 Bionic libc 类库暴露了更多的接口，包括原来在内核空间才能使用的接口，其目的是为了让用户空间的驱动可以充分的利用内核和硬件资源。若是状况果然如此，Bionic libc类库是 Google 的后门，这也可能 Android 抛弃使用 gnu glibc 重写 Bionic libc 的其中一个主要缘由。Edward J. Naughton 说：

Some of the calls exposed by Bionic are ordinarily not available to userspace because they’re excluded by the use of the #ifdef __KERNEL__ … #endif guards. If Google can define any call to the kernel from userspace as a “normal system call” (even those system calls ostensibly guarded by kernel matainers) simply by including it in its new C library, then a “normal system call” becomes whatever Google (or Oracle or Microsoft) wants it to be.

Bionic 暴露了原来在用户空间不能使用的函数调用，这些调用本来在代码中被 __KERNEL__ 的宏定义保护其运行在内核状态。若是Google 只要将在 Bionic 添加暴露的接口就能够自由的暴露 Linux 系统调用（这些系统调用明显应该由 Linux 内核社区维护），那么不免被其余人效仿。

总结

总 得说来，Android 为 GPL 下的 Linux 如何与商业社会并存与双赢提供了一个成功的范本，尝试为 Linux 生态系统上的各类角色划清彼此的做用范围，梳理了各方在版权上的权利和义务，目前看来得到了惊人的商业成功。然而，这种工做模式也面临着巨大的版权争议， 理论上存在一种可能，一旦版权模式被否决，将面临被全盘否认的灾难。

相关连接：

一、鸟哥的Linux私房菜关于GPL的解释

二、鸟哥的Linux私房菜网络版本

三、本文原文地址：http://www.oschina.net/news/29401/android-gpl-license