专有软件的开发人员有时对嵌入式Linux平台持怀疑态度,这是由于其应用程序的开源许可(如GPL (GNU公共许可证))的含义。他们担心在Linux上运行可能会使他们承担系统上其他软件组件的开源许可的义务,这样他们可能会被要求(通过诉讼)与竞争对手、客户或公众分享他们的源代码。
虽然不是假装提供法律建议,但本文根据我们的许多客户使用通用平台(如Digi Embedded Yocto、Linaro、Android等)的典型经验,为那些考虑在开源平台上部署专有应用程序的人提供了一些实用的提示和建议。
![](//www.phdurl.com/getattachment/Blog/post/Open-Source-Licenses-and-Applications-on-Embedded/GettyImages-1081869350-1280x720.jpg?lang=en-US)
Android作为一个开源的选择
无可否认,避免GPL暴露的最安全、最可靠的方法是根本不要在GNU/Linux上运行:b谷歌的Android操作系统为嵌入式设备提供了一个开源的替代方案,它从一开始就故意设计,从其用户空间环境中消除GPL许可的软件,以支持具有更宽松许可证(如Apache或BSD许可证)的组件,这些组件不需要派生作品的开发人员共享其源代码。
现代Android发行版基本上不包含GPL组件(除了Linux内核本身,它对应用程序没有任何限制)。发行版可用于常见硬件(包括Digi的ConnectCore®SOMs),并且Android已成功移植到许多自定义嵌入式板。
另一方面,Android传统上不太适合无头系统,在某种程度上,它是一个由移动电话供应商和蜂窝运营商维护的操作系统。虽然现在在手机上开发应用的人才很多,但在社区中,使用嵌入式Android开发BSP (board-support packages,主板支持包)经验丰富的开发者并不多见。
嵌入式GNU/Linux上的GPL考虑
嵌入式Linux继续享有各种各样的硬件支持,以及在所有级别的软件堆栈上工作的大型开发人员社区。对于那些不反对使用GPL软件的系统的人来说,它可以是一个优秀的、可靠的平台选择。至少在我们的经验中,绝大多数应用程序软件开发人员不会遇到与客户、竞争对手或公众之间的法律问题。
然而,嵌入式Linux上的应用程序开发人员应该记住一些基本概念和经验法则。我们将介绍以下内容:
- GPL基础
- 应用程序与驱动程序
- 开源库
- 静态链接与动态链接
- 进程间通信
- 标准C库
- Python和其他编程语言
GPL基础
gpl许可的软件是开源的:源代码必须与软件分发给的任何人共享。但是GPL (GPLv2和GPLv3)的基本和最显著的概念是堂吉诃德》: GPL许可适用于任意派生作品,即其他软件,例如通过与GPL库链接而合并GPL软件的应用程序。简而言之,如果您的应用程序与GPL软件链接或以任何其他方式合并,那么您可能有义务共享您的源代码。
应用程序与驱动程序
在Linux系统上,驱动程序通常是使用Linux内核编译的组件,它们必须遵守GPL。如果您为Linux编写驱动程序,您可能需要共享您的源代码,就像所有主要的芯片供应商(NXP, TI, Intel等)所做的那样。有一些供应商以二进制形式分发内核模块(主要用于加密设备和其他非常敏感的硬件),但这些非自由驱动程序的法律地位尚未解决。
在任何情况下,大多数外围设备在驱动软件操作的总线接口级别上都没有严重的IP问题。当硬件设备确实包含有价值的IP时,它通常在设备内部的固件中进行管理,而不是通过总线接口暴露给驱动程序。另一方面,应用程序在用户空间级别运行:它可以与Linux内核通信(通过库的系统调用),但是人们普遍认为应用程序对Linux内核没有任何许可依赖。
开源库
C/ c++应用程序通常必须与公共可用的库链接以访问系统设施,避免重复发明轮子。(例如,使用蓝牙的C程序可能需要链接libbluetooth,它是BlueZ堆栈的一部分,并获得gpl许可。)由于GNU/Linux上的许多系统库都是GPL许可的,应用程序可以通过与它们链接来承担GPL义务。
静态链接与动态链接
人们普遍认为链接动态(而不是静态地)保护应用程序不受GPL继承,但实际上这是一个尚未在法庭上完全解决的争议问题。FSF(自由软件基金会,与GNU有关联)坚持GPL做扩展到动态链接的代码:https://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynamic。
进程间通信
另一方面,C/ c++应用程序不需要与每个系统库链接。许多应用程序没有libbluetooth或其他gpl许可的库也能很好地运行。如果应用程序没有包含GPL许可的软件,即使它在GNU环境中运行,也没有GPL义务。如果应用程序执行与GPL组件的进程间通信(例如使用DBus与systemd或其他守护进程通信),那么通常可以接受这样做不授予应用程序任何GPL义务。
标准C语言库
几乎任何C应用程序都需要链接的一个库是标准C库:Linux上最常见的实现是GNU的glibc。即使对于具有宽松许可证(如uclibc或musl)的嵌入式Linux系统存在其他C库选项,专有应用程序开发人员也没有必要因为许可证而避免使用GNU C库:因为它是不GPL。
GNU C库实际上是LGPL-licensed:两者之间的主要实际区别是LGPL(“Limited GPL”)明确允许动态链接:如果您的应用程序动态地(而不是静态地)链接glibc,您不承担共享您的源代码的义务。
Python和其他编程语言
其他语言呢?如果你的代码不是用C写的,你能因为没有链接到GPL库而避开GPL吗?例如,Python解释器有自己宽松的开源许可证。它没有强加任何共享资源的要求。但是Python的许可证也是兼容的GPL。如果您编写和分发Python脚本并只导入非GPL Python库,那么您可以避免GPL义务。另一方面,一些Python库是gpl许可的。(例如,如果它们依赖于底层的GNU C库,以便GPL传播到Python库。)事实证明,Python应用程序的情况与C/ c++非常相似。
外卖
专有的闭源应用程序可以与GNU/Linux系统上的GPL软件组件共存。由于动态链接在GPL下的法律地位仍然存在争议,为了避免意外承担GPL义务,一个安全的方法是确保您的应用程序不链接或直接“合并”任何GPL软件。这可能意味着要为某些C或Python库寻找替代方案。但是GNU标准C库本身并不在其中,因为它只有一个LGPL许可证。在Linux系统上运行着许多其他gpl许可的组件,但人们普遍认为,这些组件不会将其许可传播给代码没有gpl许可的应用程序派生的从他们。
我们的团队可以提供设计指导,完整的硬件设计和应用开发服务,认证支持等。联系我们开始对话。