从谷歌华为暂停合做提及——聊聊主流开源协议

引子

2019年5月20日，科技界最火爆的消息莫过于谷歌暂停支持华为部分业务。关于这个事件将产生的影响，你们能够从相关的科技媒体上找到详细的分析。比较一致的见解是：谷歌的这个作法，对于国内的华为用户，影响不大；对于海外的华为用户，尤为是在上游应用生态环境上，会有必定的影响。

这是因为，谷歌暂停合做的服务，都是在用户层面的服务GMS。用户层与安卓底层内核听从不一样的协议，所以没必要开源，进而致使替换成本高企。基于现有生态，在海外市场构建应用生态环境难度很是大。

这篇文章将尝试从这则新闻涉及的开源协议来分析一下，这个作法背后相关的逻辑，并籍此，跟各位读者聊一聊主流的开源协议。

安卓与开源协议

开源软件或称自由软件是自由获取，源代码开放的，人们能够自由地获取和使用这些软件。同时，为了维护开发者和贡献者的合法权利，使得软件可以更好的被使用并不影响软件的正常发展，开源社区开发出了各类开源协议。软件开发者能够根据软件的属性和自身须要的权责主张选择合适的开源协议；下载并使用这些软件的用户，原则上，要求遵照开源协议的要求。

众所周知，安卓系统是基于Linux的。而Linux自己是基于GPL(GNU General Public License)v2开源协议的。GPL协议规定，只要这种程序在总体上或者其某个部分来源于遵循GPL的程序，该程序的总体就必须按照GPL流通，不只该修改文本的源码必须向社会公开，并且对于这种程序的流通不许许附加修改者本身做出的限制。

用通俗的语言来说，只要一个软件使用了采用GPL开源协议的开源软件，则在分发、传播、发布过程当中，必须一并开放源代码。则这个软件也就成为了GPL开源协议的软件。这被称为GPL协议的“传染性”。

笔者曾经研究过一个开源的位图轮廓矢量化算法名曰：Potrace。由于高效的算法被普遍采用。因为其创始人使用GPL协议，所以，全部基于此算法的软件，也都清一色的使用了GPL协议。

按照这个逻辑，基于Linux的安卓，也应该开源全部的技术代码，即遵循GPLv2协议。然而，这在现实中并无发生，缘由是安卓系统自己并非遵循GPL协议的，而是采用了对商业友好的APL(Apache Software License)。该协议不强制要求后续代码开源，也为安卓上层软件、驱动等商业活动打好了基础。

那么如今问题变成了，为何基于GPL协议的软件开发的安卓能够采用APL呢？说好的“传染性”呢？

首先说明，“传染性”的边界在哪？Linux内核的做者Linus以及内核开发人员屡次强调普通系统调用为不是 GPL 的做用范围。你们在 Linux 内核的源码 COPYING 文档中也能够找到这些文字。这些澄清为 Linux 用户空间的程序采用非 GPL 的受权许可证打好了基础。

好的，既然系统调用能够不是GPL的管辖范围。这里面谷歌作了一件事情，就是把原来在内核层的驱动剥离出来，在内核中留有调用接口。并把驱动等部分提高到用户空间，造成HAL(Hardware Abstraction Layer)。一方面起到了对硬件驱动层进行抽象，防止有问题的驱动对于内核的影响，同时也把GPL的影响控制在“内核层”。

上图是 Openfoundry绘制的安卓受权许可证结构。仅仅内核部分使用了GPL2.0。所以，构建在用户空间上的应用因为听从的APL协议，不强制要求开源，避免了商业软件和GPL中开源要求的冲突。

此次谷歌对华为暂停合做的软件正位于用户空间，如GMail，Google Map，Youtube，更新推送等。

因为中国用户对这些应用以及底层服务没有很强的依赖，并且国内的安卓在用户空间这一层已经有很强的用户生态，故而问题不大。

而对于境外用户，因为用户对这些应用已经极为依赖，另外，当地的应用也或多或少地依赖这些底层服务，同时国内的应用尚且没有在境外有充分的布局。所以，目前的情况，会使得后续境外的华为用户，无软件可用。

那么，可否重建境外的软件生态呢？答案是并不容易。

一方面，这些软件并不开源，没法从源代码找到软件运做逻辑。另外一方面，即使按照黑盒方式构建出相似软件，也有法律和信任方面的问题。总而言之，这不是单纯的技术问题。

所以，笔者谨慎的推测，华为若是决定在海外挽回移动市场份额，推广自主操做系统、重建软件生态、打破垄断的局面，将是一件很是艰苦的任务，并且真的须要各方面的通力配合。不光要靠华为的努力，也须要生态链上的企业共同努力。

同时，对于依赖于闭源的操做系统的服务和软件，一样有被釜底抽薪的几率，虽然这种状况出现的几率极低，可是风险的规模也注定和企业自身的体量正相关。

常见的开源许可

除了上面提到的GPL、APL等，还有一些常见的开源协议。当咱们进行软件开发和使用其余开源软件时候，毋需以审慎的态度对待。随着国内对知识产权保护的认识逐渐提升，保护愈来愈严格，这方面的风险是每个软件做者须要考虑到的，若是选择了一个开源协议的软件，须要对相应的权责做出响应，不然可能会承担法律的风险。固然，除了义务，也有对于免责的声明，好比MIT协议：因为使用此软件形成的问题，做者能够不负责。

阮一峰老师在这篇文章对翻译了Paul Bagwell对这些开源协议的选择逻辑。

这里面，NodeJS中的ISC协议近乎等于BSD协议。

对于更复杂的状况 网友phodal总结了更多的状况：

 

还有一个来自于GcsSloop博文中基于场景的选择图

能够根据编写时候的场景进行选择：

这个网站总结了主流的开源协议。有一个帮助你选择开源协议的网站，供你们参考。

下面列出了主流的开源协议的权责义务：

主流的开源软件的选择，也许是咱们的一个参考，下面的表中列出了一些流行软件的开源许可。供你们参考。

协议	软件
MIT	babel、.net core、rails、ThinkJS
GPL	Bash、GIMP、Potrace
APL	AOSP

许可覆盖

你们在接触NodeJS开发时候，使用npm初始一个软件的时候，lisence默认是ISC。这也致使了更多的NodeJS软件是使用ISC这个开源协议，或者更进一步选择更为宽松的MIT协议。因为这都是比较宽松的协议，若是底层依赖或者想法借鉴了更为严格的协议软件。这个协议就是不合适的，由于阻断了开源协议的约束传播，就像你把一个类的Private属性变成了Public，基于此构建的软件也会忽视掉底层的协议。对于此，尤为是作类库的开发者更须要注意。

附录：近期关于lisence的一些热点事件

1. Facebook围绕React Native的BSD+Patents协议的争端
2. Redis Modules变动许可证
3. MongoDB协议更改
4. Oracle JDK 11改用商用协议

 

关于360技术

360技术是360技术团队打造的技术分享公众号，天天推送技术干货内容

更多技术信息欢迎关注“360技术”微信公众号