企业官网建设流程全解析

SRS 集成 FFmpeg 4.2 的开源许可证解析：LGPL/GPL 双轨授权与二进制分发合规指南

【免费下载链接】srsSRS is a simple, high-performance, AI-driven real-time media server supporting RTMP, WebRTC, HLS, HTTP-FLV, HTTP-TS, SRT, MPEG-DASH, and GB28181, with codec support for H.264, H.265, AV1, VP9, AAC, Opus, and G.711.项目地址: https://gitcode.com/GitHub_Trending/sr/srs

导读：本文以 SRS 仓库内随附的 FFmpeg 裁剪源码树（trunk/3rdparty/ffmpeg-4-fit）及其 LICENSE.md 文档为线索，系统梳理 FFmpeg 的 LGPL v2.1+ 与 GPL v2+ 双轨授权机制、GPL 组件的精确清单、外部库兼容性矩阵，以及 SRS 实际构建流程中如何通过--enable-gpl、--enable-version3、--enable-nonfree、--shared-ffmpeg等配置开关影响最终二进制的许可属性，帮助开发者在使用 SRS 做 WebRTC/RTMP 音视频转码时做出合规的构建与分发决策。

一、为什么 SRS 会内置一份 FFmpeg 源码树

SRS 作为支持 RTMP、WebRTC、HLS、SRT、GB28181 等多种协议的实时媒体服务器，其 WebRTC 与 RTMP 之间的音频转码（AAC 与 Opus 互转）依赖 FFmpeg 的编解码库。与直接调用系统 ffmpeg 可执行文件不同，SRS 在trunk/3rdparty/目录下维护了一份经过裁剪的 FFmpeg 4.2 源码树（ffmpeg-4-fit，即 "fit" 定制版），连同opus-1.3.1.tar.gz一起随仓库分发，构建时以静态或共享库形式链接进 SRS 主程序。

这一设计直接决定了一个关键问题：FFmpeg 自身的许可证将传导到最终二进制。因此，SRS 仓库在 ffmpeg-4-fit/LICENSE.md 中完整保留了 FFmpeg 官方的许可证说明文档，以便使用者理解这份源码树各部分的授权边界，并在分发 SRS 二进制时履行对应的许可证义务。相关依赖的定位还可以在 3rdparty/README.md 中看到：ffmpeg-4.2.tar.gz与opus-1.3.1.tar.gz的用途标注为 "To support RTMP/WebRTC transcoding"（支持 RTMP/WebRTC 转码）。

二、FFmpeg 的默认授权：LGPL v2.1+ 双轨并存

LICENSE.md 开篇即给出了 FFmpeg 的默认授权基调：

Most files in FFmpeg are under the GNU Lesser General Public License version 2.1 or later (LGPL v2.1+). Some other files have MIT/X11/BSD-style licenses. In combination the LGPL v2.1+ applies to FFmpeg.

也就是说：

• 绝大多数文件遵循 LGPL v2.1 或更高版本（LGPL v2.1+），这是 FFmpeg 二进制默认适用的许可证；
• 少量文件采用 MIT/X11/BSD 风格许可证，组合后整体仍适用 LGPL v2.1+；
• 官方还引用COPYING.LGPLv2.1作为详细法律文本，但需要说明的是，这份裁剪源码树并未包含COPYING.*系列文件（仓库中只有 LICENSE.md 与 LICENSE 两份许可文档），完整法律条款请以 FFmpeg 官方发布包为准。

从 SRS 的构建脚本可以印证这一"默认 LGPL"的工程实践：auto/depends.sh 在编译 ffmpeg-4-fit 时给出的配置项中，没有出现任何--enable-gpl，默认即构建为 LGPL 形态的库。

三、GPL 组件：精确清单与激活开关

3.1 激活方式：必须显式--enable-gpl

LICENSE.md 明确指出，FFmpeg 的部分可选组件采用 GPL v2+ 授权，并且：

None of these parts are used by default, you have to explicitly pass--enable-gplto configure to activate them. In this case, FFmpeg's license changes to GPL v2+.

即在默认配置下这些 GPL 组件不会被启用，只有在 configure 时显式传入--enable-gpl才会被激活；一旦激活，FFmpeg 整体许可证即变为 GPL v2+。SRS 的裁剪构建默认不启用该开关，因此在常规./configure && make流程下产出的 FFmpeg 库保持 LGPL 属性（参见 auto/depends.sh）。

3.2 GPL 组件清单（完整列表）

LICENSE.md 列出的 GPL 部分包括四类：

（1）libpostproc 库：整个库属于 GPL 组件。

（2）libavcodec/x86 下的三个可选 x86 优化文件：

• libavcodec/x86/flac_dsp_gpl.asm
• libavcodec/x86/idct_mmx.c
• libavfilter/x86/vf_removegrain.asm

（3）构建与测试工具：

• compat/solaris/make_sunver.pl
• doc/t2h.pm
• doc/texi2pod.pl
• libswresample/swresample-test.c
• tests/checkasm/*
• tests/tiny_ssim.c

（4）libavfilter 中的 32 个滤镜：

vf_blackframe.c、vf_boxblur.c、vf_colormatrix.c、vf_cover_rect.c、vf_cropdetect.c、vf_delogo.c、vf_eq.c、vf_find_rect.c、vf_fspp.c、vf_geq.c、vf_histeq.c、vf_hqdn3d.c、vf_interlace.c、vf_kerndeint.c、vf_mcdeint.c、vf_mpdecimate.c、vf_owdenoise.c、vf_perspective.c、vf_phase.c、vf_pp.c、vf_pp7.c、vf_pullup.c、vf_repeatfields.c、vf_sab.c、vf_smartblur.c、vf_spp.c、vf_stereo3d.c、vf_super2xsai.c、vf_tinterlace.c、vf_uspp.c、vsrc_mptestsrc.c。

值得注意：SRS 的 ffmpeg-4-fit 裁剪配置在 auto/depends.sh 中通过--disable-avfilter、--disable-postproc显式禁用了 libavfilter 与 libpostproc，并且禁用列表中还包含--disable-swscale、--disable-avformat、--disable-avdevice、--disable-network等一大串特性。这意味着上述 GPL 滤镜和 libpostproc 在 SRS 的默认裁剪构建中不会进入最终库，从源码结构看，这既是为了压缩体积，也天然规避了 GPL 组件的引入。

3.3 升级到 (L)GPL v3 的开关

LICENSE.md 还提供了第三条授权路径：

Should you, for whatever reason, prefer to use version 3 of the (L)GPL, then the configure parameter--enable-version3will activate this licensing option for you. Read the fileCOPYING.LGPLv3or, if you have enabled GPL parts,COPYING.GPLv3to learn the exact legal terms that apply.

即在 configure 时传入--enable-version3可将授权升级到 LGPL v3 / GPL v3。SRS 默认不启用此选项；但在后续会看到，当需要链接 Apache 2.0 协议的外部库时，这个开关是必要的前提（见第五节）。

FFmpeg 自带的 configure 脚本（trunk/3rdparty/ffmpeg-4-fit/configure）中可以看到这三个开关的原始定义：--enable-gpl（"allow use of GPL code, the resulting libs..."）与--enable-version3（"upgrade (L)GPL to version 3 [no]"），与 LICENSE.md 的表述完全一致。

四、其他授权条款的少量文件

LICENSE.md 单独列出了少量采用其他授权条款的文件：

• 来自 libjpeg 的三个文件：libavcodec/jfdctfst.c、libavcodec/jfdctint_template.c、libavcodec/jrevdct.c。它们要求：如果只分发可执行文件，必须在随程序分发的文档中向 IJG（Independent JPEG Group）致谢；同时必须在文档中注明对这三个文件的任何修改（包括增删）。
• tests/reference.pnm：采用 expat 许可证（Expat 即 MIT 风格许可证的一种）。

从源码结构看，SRS 的 ffmpeg-4-fit 中保留了libavcodec下的 JPEG 相关源码（如libavcodec/jfdctfst.c、libavcodec/jrevdct.c等目录列表可见），因此这一条对 SRS 集成场景同样适用：若分发 SRS 二进制，需留意对 IJG 的署名与修改声明义务。

五、外部库兼容性矩阵：三类许可证组合

FFmpeg 可以与大量外部库组合，这些组合会改变最终二进制的授权性质。LICENSE.md 将其划分为"兼容库"与"不兼容库"两类。

5.1 兼容库（GPL 类：需--enable-gpl）

以下库本身采用 GPL 授权，与它们组合时 FFmpeg 也必须以 GPL 授权：

• frei0r
• libcdio
• librubberband
• libvidstab
• libx264
• libx265
• libxavs
• libxvid

组合时需在 configure 中传入--enable-gpl，使 FFmpeg 以 GPL v2+ 授权。

5.2 兼容库（Apache 2.0 类：需--enable-version3）

OpenCORE 和 VisualOn 库采用 Apache License 2.0。该许可证与 LGPL v2.1 和 GPL v2不兼容，但与 v3 版本的 LGPL/GPL 兼容。因此要与这两个库组合，必须通过--enable-version3将许可证版本升级到 v3。

5.3 不兼容库（需--enable-nonfree，谨慎评估）

某些库的许可证与 GPL/LGPL 不兼容：

• Fraunhofer FDK AAC 与 OpenSSL：其许可证与 GPLv2 和 GPLv3 均不兼容；据文档所述，它们与 LGPL 兼容。注意 SRS 为支持 RTMP 复杂握手与 SRTP，本身集成了自己的 OpenSSL 构建路径（见 configure 与 3rdparty/README.md 中openssl-1.1-fit的说明），但 FFmpeg 侧的 OpenSSL 组合需另行评估。
• NVENC 库：虽然头文件采用兼容的 MIT 许可证，但运行时需要一个专有的二进制 blob，因此被认定与 GPL 不兼容；即使采用 LGPL 配置，FFmpeg 官方也要求传入--enable-nonfree（以防它与 LGPL 不兼容）。

若传入--enable-nonfree启用这些库，最终二进制将处于"复杂的许可证混合"状态，比 LGPL 更严格，可能带来额外义务，甚至导致二进制无法再分发。文档措辞明确：

It is possible that these restrictions cause the resulting binary to be unredistributable.

六、SRS 中 FFmpeg 相关的构建开关与许可联动

理解了 FFmpeg 的授权体系后，再看 SRS 在 auto/options.sh 中暴露的相关配置开关，二者是直接对应的：

其中与许可证最相关的是--shared-ffmpeg：SRS 在 auto/options.sh 的注释中直接写明 "If enabled, link shared libraries for FFmpeg which is LGPL license"（启用后以 LGPL 授权的共享库方式链接 FFmpeg）。对应地，auto/depends.sh 在SRS_SHARED_FFMPEG == YES时给 FFmpeg 追加--enable-shared构建参数，而 trunk/configure 则把链接方式从静态.a文件切换为-lavcodec -lswresample -lavutil动态库链接。

合规提示（基于文档与源码的推断，不构成法律意见）：默认的--ffmpeg-fit=on与--shared-ffmpeg=off组合，意味着 FFmpeg 的 libavcodec、libswresample、libavutil 以静态库形式链入 SRS 主程序。对于 LGPL 库的静态链接分发，使用者通常需要审视 LGPL v2.1 对"可被替换"（relinkable）的要求；SRS 提供--shared-ffmpeg=on正是为了给需要以 LGPL 合规方式分发二进制的用户一条更省心的路径。具体义务请以 LGPL v2.1 法律文本与法律顾问意见为准。

七、FFmpeg 转码链路在 SRS 中的实际落点

为说明许可证讨论对应的真实功能，这里补充 SRS 中 FFmpeg 库的实际使用位置：

• 进程级转码（工具模式）：SRS 的 srs_app_ffmpeg.cpp 负责管理外部 ffmpeg 可执行进程（SrsFFMPEG类封装了参数构造与进程启动），用于transcode/ingest等场景；此时 SRS 与 ffmpeg 是两个独立进程，许可证层面互不传染。
• 库内联转码（链接模式）：SRS 为 WebRTC 场景将 FFmpeg 的libavcodec/libswresample/libavutil（以及 Opus 的libopus）直接链接进 SRS 进程，用于 AAC↔Opus 音频转码——这正是前面讨论的 LGPL 静态/动态链接问题的实际来源。相关链接参数见 trunk/configure，其中还包含-lrt（Linux 下 FFmpeg 所需）等细节。

八、构建与再分发时的许可证自检清单

综合 LICENSE.md 与 SRS 构建脚本，可整理出一份可操作的检查清单：

1. 默认构建：./configure && make，FFmpeg 以 LGPL v2.1+ 静态库链入；分发前评估 LGPL 静态链接义务。
2. 希望规避 LGPL 静态链接传染：加--shared-ffmpeg=on，以动态库分发 FFmpeg 部分。
3. 需要链接 GPL 类外部库（libx264 等）：必须启用 FFmpeg 的--enable-gpl，此时 FFmpeg 整体升级为 GPL v2+，SRS 二进制的分发义务随之变化——注意 SRS 默认不启用此开关。
4. 需要链接 Apache 2.0 的 OpenCORE/VisualOn：必须加--enable-version3升级到 (L)GPL v3。
5. FDK-AAC / OpenSSL / NVENC 等非自由组件：需--enable-nonfree，接受更严格的混合授权，甚至可能不可再分发，商业分发前务必评估。
6. 分发文档义务：若涉及 libjpeg 来源的三个文件，需在文档中致谢 IJG 并声明修改；关注 IJG 署名条款。
7. 查看详细法律文本：LICENSE.md 指引的COPYING.LGPLv2.1、COPYING.GPLv2、COPYING.LGPLv3、COPYING.GPLv3文件需从 FFmpeg 官方发布包获取（SRS 裁剪树未随附）。

九、总结

SRS 之所以把 FFmpeg 4.2 的许可证文档原样保留在 trunk/3rdparty/ffmpeg-4-fit/LICENSE.md，是因为这份内嵌源码树的授权属性直接决定了 SRS 二进制分发的合规边界。FFmpeg 默认的 LGPL v2.1+ 授权、--enable-gpl激活 GPL v2+ 组件的双轨机制、--enable-version3的版本升级路径，以及--enable-nonfree带来的"可能不可再分发"风险，共同构成了一套需要在构建期就做出明确决策的授权矩阵。SRS 的默认裁剪构建恰好避开了 GPL 滤镜、libpostproc 等 GPL 组件，并通过--shared-ffmpeg开关为分发者提供了动态链接的合规选项——理解这层关系，是在生产环境部署和再分发 SRS 时做出正确选择的前提。

【免费下载链接】srsSRS is a simple, high-performance, AI-driven real-time media server supporting RTMP, WebRTC, HLS, HTTP-FLV, HTTP-TS, SRT, MPEG-DASH, and GB28181, with codec support for H.264, H.265, AV1, VP9, AAC, Opus, and G.711.项目地址: https://gitcode.com/GitHub_Trending/sr/srs