Qt软件中的LGPL/GPL传染性分析及合规建议

　　Qt是Qt Company开发的跨平台C++图形用户界面应用程序开发框架，可构建高性能的桌面、移动及Web应用程序，也可用于开发非GUI程序，比如控制台工具和服务器。[1]由于其跨平台应用的特性，Qt被广泛应用于软件开发实践中，根据Qt网站的介绍，使用Qt进行开发的设备和应用程序超过10亿台（个）。[2]

　　Qt框架的大部分模块采用双重许可，可以在商业许可证和开源许可证两种模式下使用，少数模块仅通过商业许可证授权使用。在开源许可的模式中，Qt主要适用的开源许可证为LGPLv3，包括Qt所有基本库及部分扩展库。适用LGPL的模块也同时适用GPL，也有部分模块仅适用GPL（不同时适用LGPL）[3]。 为了解决部分开发场景中必须通过静态链接实现的问题，个别模块（如QtMain库中的QaX服务器，QaX容器）适用BSD许可证。

以下，笔者结合LGPL、GPL许可证的要求，分析在商业软件中使用QT这两类许可证模块的传染性，并提出合规建议。

1. LGPL

　　LGPL由自由软件基金会于1991年发布，最初版本名称为Library General Public License v2（LGPL 2.0），1999年重命名为Lesser General Public License v2.1（LGPL 2.1），最新版本为Lesser General Public License v3（LGPL 3.0）。Qt库中适用LGPL的模块包括QT基本库中的所有模块以及扩展库中的部分模块。适用LGPL的模块，绝大多数适用LGPL v3，有个别模块（如Qt WebEngine）适用LGPL v2.1。

　　根据LGPL的要求，分发修改后的LGPL库，也需要适用LGPL进行开源。在使用Qt框架开发商业软件的过程中，建议企业尽量不要修改Qt中的LGPL库。QT框架的LGPL模块，大多数都适用LGPL v3。GPL v3第3条规定，用户为实现许可证赋予的权利义务，对适用GPL v3的软件采取规避技术措施的，企业具有容忍义务。LGPL v3第1条设定了豁免该容忍义务的条件，并不包括对LGPL库进行修改的情况。如果企业修改了LGPL库，则不享有这种豁免。用户为实现许可证赋予的权利义务而规避技术措施的，企业不得追究用户的法律责任。

　　通过动态链接使用LGPL库，专有软件不需要适用LGPL，不需要开源，建议企业尽量通过动态链接调用Qt框架中的LGPL模块。通过静态链接使用Qt框架中的LGPL模块，专有软件部分如何受影响，是否需要开源，需要根据具体场景分析。根据LGPL的条款，通过静态链接使用LGPL库，需要履行两个义务，并确保一个实现结果，即：提供“最小源代码”，分发应用程序的代码（源代码或目标代码均可），并确保用户在修改LGPL库后，仍然可以与应用程序重新组合使用。在某些开发场景中，为了实现这种结果，企业可能需要履行较高的开源义务。根据Qt官网的建议，对于Qt中的LGPL库，要么以动态链接的方式使用，要么按照LGPL提供源代码。[4]

2.GPL

GPL，全称为GNU General Public License，允许接收者免费并自由使用、修改、分发适用GPL的开源软件，同时要求分发基于GPL软件开发的衍生软件或组合的软件整体也适用GPL。

　　Qt框架中适用LGPL的模块，同时也适用GPL，也有部分模块仅适用GPL（比如QT HTTP Server）。适用GPL的这些模块，绝大多数适用GPL v3。但考虑到与GNU/Linux、MySQL等仅适用GPL v2的开源软件组合的开发场景，部分模块同时适用GPLv2（比如QT XML、QT SQL）。另有个别模块，仅适用GPL v2（比如Qt WebEngine），不适用GPL v3。[5]

　　GPL具有很强的传染性，通过复制、合并、修改GPL软件开发的衍生软件要适用GPL，与GPL软件链接（含动态链接和静态链接）、组合的软件整体也要适用GPL。GPL的传染性仅在软件被分发的情况下触发，同时具有Linux内核系统调用的例外情形和进程间通信的隔离措施。以下，笔者分别进行分析：

2.1 未分发GPL软件不会触发传染性

　　基于GPL软件开发的衍生软件，没有对外分发的，不会被GPL传染，不需要开源，具体包括以下场景：

▌企业内部使用

　　使用Qt中的GPL模块开发的衍生软件，仅在企业内部使用（比如作为内部OA办公软件、内部员工信息管理软件），未分发给用户的，不会触发GPL的传染性，不需要开源。

▌仅将GPL软件作为开发工具使用

　　使用适用GPL的QT开发工具（比如Qt Creator）开发形成的软件，不受工具的许可证影响，无论是否分发，均不会被GPL传染，不需要开源。如果开发形成的软件被分发，且在编译、解释或运行时，会复制、调用或链接QT框架中适用GPL的库，则该软件也需要适用GPL进行开源。

▌仅在服务器端软件中使用

　　Qt 被广泛用于跨平台的 GUI 开发，但其底层框架也包含大量非 GUI 模块，可以用于开发服务器端软件。使用Qt软件的GPL模块开发的服务器软件，通常只在服务器端使用，不会分发给用户，不需要开源。

▌仅在SaaS环境中部署Qt框架的GPL模块

　　Qt框架的跨平台性，使其能够应用在各种云计算平台。与服务器端软件类似，使用Qt框架中的GPL模块开发的软件，如果仅在SaaS中部署，没有分发给用户，不需要开源。

2.2 Linux内核系统调用例外

　　Linux内核适用GPL v2，用户空间应用程序通过正常系统调用使用Linux内核，不会被传染，不需要适用GPL v2。在Linux环境中使用Qt进行开发，可能涉及两个开发场景：

▌在Linux内核模块中嵌入Qt库

　　Qt一般被用于设计用户空间应用程序，仅在特定场景中需要在Linux内核嵌入Qt模块，比如图形界面、复杂的数据结构。在这类场景中，用户空间应用程序通过正常系统调用接口调用嵌入了Qt库的Linux内核，不会被GPL v2传染，不需要开源。

▌用户空间应用程序使用Qt框架调用Linux内核

　　Qt 框架通过C标准库或API封装了Linux内核系统调用功能，例如通过QFile实现内核的open等系统调用功能，通过QTcpSocket实现socket等系统调用功能。用户空间程序无需直接调用syscall接口，即可通过Qt框架调用Linux内核，不需要适用GPL v2。

2.3 使用不同进程之间的通信机制

　　专有软件使用pipes、sockets、命令行参数等不同进程之间的通信机制与GPL软件进行通信，相互之间未交换复杂内部数据结构的，不会被传染。

　　Qt的部分附加模块，仅适用GPL或商业许可证，而不适用LGPL，比如 Qt Wayland Compositor, Qt Application Manager。将Qt中适用GPL的模块设计成独立应用程序在单独进程中运行，专有软件通过Qt Remote Objects 或者 gRPC等进程间通信、远程过程调用机制与其通信，相互之间未交换复杂内部数据结构的，不会被GPL传染，不需要开源。对于进程之间采取什么通信机制，交换什么信息，可以隔离GPL的传染性，自由软件基金会并未进一步说明，其认为该问题应该由法官最终决定。在商业软件使用Qt的GPL模块的过程中，通过专有软件与GPL模块运行在独立进程并实现不同功能、进程间使用标准化通信协议（而非自定义协议或者Qt自带的QDBus）、避免共享内存和数据结构的软件架构设计，有助于降低专有软件被GPL模块传染、需要开源的法律风险。

参考文献

１、https://www.qt.io/licensing/open-source-lgpl-obligations

2、https://baike.baidu.com/item/Qt/451743

3、https://www.qt.io/qt-success-stories

4、https://www.qt.io/product/features

5、https://www.qt.io/licensing/open-source-lgpl-obligations