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-gplLICENSE.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, FFmpegs 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 部分包括四类1libpostproc 库整个库属于 GPL 组件。2libavcodec/x86 下的三个可选 x86 优化文件libavcodec/x86/flac_dsp_gpl.asmlibavcodec/x86/idct_mmx.clibavfilter/x86/vf_removegrain.asm3构建与测试工具compat/solaris/make_sunver.pldoc/t2h.pmdoc/texi2pod.pllibswresample/swresample-test.ctests/checkasm/*tests/tiny_ssim.c4libavfilter 中的 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-gplallow use of GPL code, the resulting libs...与--enable-version3upgrade (L)GPL to version 3 [no]与 LICENSE.md 的表述完全一致。四、其他授权条款的少量文件LICENSE.md 单独列出了少量采用其他授权条款的文件来自 libjpeg 的三个文件libavcodec/jfdctfst.c、libavcodec/jfdctint_template.c、libavcodec/jrevdct.c。它们要求如果只分发可执行文件必须在随程序分发的文档中向 IJGIndependent 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 授权frei0rlibcdiolibrubberbandlibvidstablibx264libx265libxavslibxvid组合时需在 configure 中传入--enable-gpl使 FFmpeg 以 GPL v2 授权。5.2 兼容库Apache 2.0 类需--enable-version3OpenCORE 和 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 中暴露的相关配置开关二者是直接对应的SRS 配置开关默认值说明与许可证的关系--ffmpeg-fiton\|offon是否编译内置 FFmpeg 裁剪源码决定是否将 FFmpeg默认 LGPL链接进 SRS--ffmpeg-opuson\|offoff是否使用 FFmpeg 原生 Opus 编解码器替代外部 libopus切换音频转码实现不影响许可证类别--shared-ffmpegon\|offoff是否以共享库方式链接 FFmpeg以 LGPL 动态链接方式分发规避静态链接下的 LGPL 传染问题--use-sys-ffmpeg/--sys-ffmpegon\|offoff不编译内置 FFmpeg改用系统 FFmpeg由系统 FFmpeg 的构建参数决定许可证其中与许可证最相关的是--shared-ffmpegSRS 在 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-fiton与--shared-ffmpegoff组合意味着 FFmpeg 的 libavcodec、libswresample、libavutil 以静态库形式链入 SRS 主程序。对于 LGPL 库的静态链接分发使用者通常需要审视 LGPL v2.1 对可被替换relinkable的要求SRS 提供--shared-ffmpegon正是为了给需要以 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其中还包含-lrtLinux 下 FFmpeg 所需等细节。八、构建与再分发时的许可证自检清单综合 LICENSE.md 与 SRS 构建脚本可整理出一份可操作的检查清单默认构建./configure makeFFmpeg 以 LGPL v2.1 静态库链入分发前评估 LGPL 静态链接义务。希望规避 LGPL 静态链接传染加--shared-ffmpegon以动态库分发 FFmpeg 部分。需要链接 GPL 类外部库libx264 等必须启用 FFmpeg 的--enable-gpl此时 FFmpeg 整体升级为 GPL v2SRS 二进制的分发义务随之变化——注意 SRS 默认不启用此开关。需要链接 Apache 2.0 的 OpenCORE/VisualOn必须加--enable-version3升级到 (L)GPL v3。FDK-AAC / OpenSSL / NVENC 等非自由组件需--enable-nonfree接受更严格的混合授权甚至可能不可再分发商业分发前务必评估。分发文档义务若涉及 libjpeg 来源的三个文件需在文档中致谢 IJG 并声明修改关注 IJG 署名条款。查看详细法律文本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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考