FFmpeg 许可体系全解：LGPL v2.1 主体、GPL 可选组件与 configure 三大许可选项

FFmpeg 采用“LGPL v2.1+ 为主体、GPL v2+ 组件可选启用、version3 按需升级”的混合许可架构，其完整说明见仓库根目录的 LICENSE.md。本篇基于该文档逐节展开，并结合 configure 脚本中的许可检查逻辑与 GPL 组件源码，说明三大许可选项（--enable-gpl、--enable-version3、--enable-nonfree）的确切含义、触发条件与分发约束，帮助你在构建 FFmpeg 前做出符合自身分发场景的许可选择。

1. 许可总览：为什么默认构建是 LGPL v2.1+

LICENSE.md 开篇即给出 FFmpeg 的许可基调：

• 绝大多数文件位于 GNU Lesser General Public License version 2.1 or later（LGPL v2.1+）之下，完整文本见 COPYING.LGPLv2.1；
• 另有部分文件采用 MIT/X11/BSD 风格的宽松许可；
• 这些许可组合在一起，使 FFmpeg 整体以 LGPL v2.1+ 对外生效。

选择 LGPL 作为默认许可的直接后果是：FFmpeg 可以作为一个库被动态链接进专有（闭源）软件中分发，这是 FFmpeg 生态（播放器、转码服务等商业集成）能够存在的基础。仓库内四份许可全文文件可供查阅：

文件	内容
COPYING.LGPLv2.1	默认许可文本（LGPL 2.1）
COPYING.LGPLv3	--enable-version3 时生效的 LGPL 3
COPYING.GPLv2	启用 GPL 组件时的许可文本
COPYING.GPLv3	启用 GPL 组件并升级 version3 时的许可文本

2. GPL v2+ 可选组件：--enable-gpl 会启用什么

LICENSE.md 明确说明：FFmpeg 中存在一部分 GPL v2 or later（GPL v2+） 许可的代码，它们默认不参与构建，必须显式向 configure 传入 --enable-gpl 才会被激活；一旦激活，FFmpeg 的整体许可就从 LGPL v2.1+ 变为 GPL v2+。

文档逐项列出了 GPL 组件的范围，这里完整继承并转为仓库根目录相对路径：

2.1 可选的 x86 汇编优化

• libavcodec/x86/flac_dsp_gpl.asm —— FLAC 解码的 GPL 汇编加速
• libavcodec/x86/idct_mmx.c —— 文档列出的 IDCT MMX 优化
• libavfilter/x86/vf_removegrain.asm —— removegrain 滤镜的 x86 加速

需要指出一个事实差异：在当前仓库快照中，libavcodec/x86/idct_mmx.c 已不存在（该 IDCT MMX 实现后来被重构进 simple_idct 模板与 x86/simple_idct*.asm 体系，见 libavcodec/simple_idct_template.c 中对 mpeg2dec 的引用注释）。这说明 GPL 组件清单随代码演化会收缩，--enable-gpl 的实际影响范围以当前 configure 中的依赖声明为准。

2.2 构建与测试工具

• compat/solaris/make_sunver.pl
• doc/t2h.pm、doc/texi2pod.pl
• libswresample/tests/swresample.c
• tests/checkasm/ 整个目录
• tests/tiny_ssim.c

2.3 libavfilter 中的 GPL 滤镜（完整清单）

libavfilter/signature_lookup.c 以及下列滤镜均为 GPL 许可，全部位于 libavfilter/ 目录下：

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_histeq.c、vf_hqdn3d.c、vf_kerndeint.c、vf_lensfun.c（GPL v3 or later，见 3 节）、vf_mcdeint.c、vf_mpdecimate.c、vf_nnedi.c、vf_owdenoise.c、vf_perspective.c、vf_phase.c、vf_pp7.c、vf_pullup.c、vf_repeatfields.c、vf_sab.c、vf_signature.c、vf_smartblur.c、vf_spp.c、vf_stereo3d.c、vf_super2xsai.c、vf_tinterlace.c、vf_uspp.c、vf_vaguedenoiser.c，以及测试源 libavfilter/vsrc_mptestsrc.c。

2.4 configure 如何强制这一约束

从 configure 的源码结构看，每个 GPL 滤镜都带有 deps="gpl"（或附加依赖）的声明，例如：

blackframe_filter_deps="gpl"
boxblur_filter_deps="gpl"
lensfun_filter_deps="liblensfun version3"

这意味着即使构建了 --enable-gpl，滤镜仍要满足其组件依赖（如 liblensfun）才会真正编译进二进制。换句话说，许可声明与组件依赖在同一套 deps 机制里统一裁决。

3. 升级到 version 3：--enable-version3

configure 的 help 文本给出了三个许可开关的官方定义：

--enable-gpl             allow use of GPL code, the resulting libs
                          will be under GPL (or LGPL if --disable-gpl)
--enable-version3        upgrade (L)GPL to version 3 [no]
--enable-nonfree         allow use of nonfree code, the resulting libs
                         will be non redistributable

LICENSE.md 说明：如果你出于任何原因偏好使用 (L)GPL 的第 3 版，向 configure 传入 --enable-version3 即可激活该许可选项。此时：

• 未启用 GPL 组件 → 阅读 COPYING.LGPLv3 了解适用的法律条款；
• 已启用 GPL 组件 → 阅读 COPYING.GPLv3。

--enable-version3 本身不改变 GPL/LGPL 的“严格 vs 宽松”性质，只是把许可版本从 v2 抬升到 v3（v3 增加了反 Tivoization 等附加条款，因此对分发方意味着更强的义务）。它同时也是组合 Apache 2.0 外部库的必要前提（见 5.1 节）。

4. 其他许可条款下的少数文件

LICENSE.md 特别列出两类不属于 (L)GPL 体系的文件，分发时容易忽略其义务：

4.1 源自 IJG libjpeg 的三个 DCT 文件

• libavcodec/jfdctfst.c
• libavcodec/jfdctint_template.c
• libavcodec/jrevdct.c

打开任一文件即可看到文件头部保留了 IJG（Independent JPEG Group）的原始许可声明。文档强调了两条分发义务：

1. 如果你只分发可执行文件（不分发这三个文件的源码），必须在随程序提供的文档中署名致谢 IJG；
2. 必须指明你对这三个文件所做过的任何改动（包括新增与删除）。

4.2 Expat 许可的测试参考图

• tests/reference.pnm 位于 expat 许可之下（宽松许可，保留版权声明即可）。

5. 外部库的许可影响：组合决定一切

LICENSE.md 的 “External libraries” 一节指出：FFmpeg 可组合大量外部库，某些组合会改变最终二进制的许可性质。configure 用四个外部库分组变量实现了这一裁决（见 configure）：EXTERNAL_LIBRARY_GPL_LIST、EXTERNAL_LIBRARY_NONFREE_LIST、EXTERNAL_LIBRARY_VERSION3_LIST、EXTERNAL_LIBRARY_GPLV3_LIST。

5.1 兼容库（compatible）

GPL v2 许可的库：avisynth、frei0r、libcdio、libdavs2、librubberband、libvidstab、libx264、libx265、libxavs、libxavs2、libxvid。 与它们组合时，FFmpeg 必须同时升为 GPL，即必须传 --enable-gpl。

LGPL v3 许可的库：gmp、libaribb24、liblensfun。 与它们组合时，需用 --enable-version3 把 FFmpeg 升级到 LGPL v3。

Apache License 2.0 的库：VMAF、mbedTLS、RK MPI、OpenCORE、VisualOn。 Apache 2.0 与 LGPL v2.1 和 GPL v2 不兼容，但与两个许可的 version 3 兼容。因此组合这些库必须传 --enable-version3 抬升许可版本。

GPL v3 的库：smbclient。 与它组合需要同时传 --enable-gpl 和 --enable-version3，FFmpeg 最终升为 GPL v3。这一点在 configure 中也有对应声明：

libsmbclient_protocol_deps="libsmbclient gplv3"

5.2 不兼容库与 --enable-nonfree

存在某些许可与 GPL 和/或 LGPL 均不兼容的库。文档说明：如果即便在许可不兼容的情况下仍要启用它们，向 configure 传 --enable-nonfree。代价是：最终二进制不可再分发（unredistributable）——你可以在自己机器上使用它，但不能合法地向第三方分发。

文档举出的例子：

• Fraunhofer FDK AAC 与 OpenSSL 的许可与 GPLv2/v3 不兼容；按文档表述（"To the best of our knowledge"），据当前维护者所知它们与 LGPL 兼容。

5.3 configure 的许可冲突拦截逻辑

从 configure 的源码结构看，这些约束不是文档上的“君子协定”，而是构建时的硬性检查：

die_license_disabled_gpl() {
    enabled $1 || { enabled $v && die "$v is incompatible with the gpl and --enable-$1 is not specified."; }
}
map "die_license_disabled gpl"      $EXTERNAL_LIBRARY_GPL_LIST $EXTERNAL_LIBRARY_GPLV3_LIST
map "die_license_disabled version3" $EXTERNAL_LIBRARY_VERSION3_LIST $EXTERNAL_LIBRARY_GPLV3_LIST
enabled gpl && map "die_license_disabled_gpl nonfree" $EXTERNAL_LIBRARY_NONFREE_LIST

即：启用了 GPL 外部库却未给 --enable-gpl、或启用了 version3 库却未给 --enable-version3，configure 会直接 die 报错中止，而不是静默产出违规产物。反过来，若你已 --enable-gpl，再启用 nonfree 库也会被专门拦截。

6. 实操速查：许可选项组合与后果

综合 LICENSE.md 与 configure 的检查逻辑，常见构建组合及其许可结果如下：

configure 选项组合	FFmpeg 生效许可	能否再分发	典型场景
（无附加选项，默认）	LGPL v2.1+	可	动态链接进商业软件
--enable-gpl	GPL v2+	可（按 GPL v2 义务）	需要 x264/x265、GPL 滤镜等
--enable-version3	LGPL v3+	可	组合 Apache 2.0 / LGPL v3 库
--enable-gpl --enable-version3	GPL v3+	可（按 GPL v3 义务）	组合 smbclient（GPL v3）
任意 + --enable-nonfree	不可再分发	不可	FDK AAC、OpenSSL 等

几点补充提醒：

1. 许可变化是整体性的：只要启用了任何一个 GPL 组件，整个 FFmpeg 就从 LGPL 变为 GPL，而不是“只有那部分代码是 GPL”；
2. IJG 义务独立于构建选项：jfdctfst.c 等三个文件在任何构建中都可能参与编译，只分发可执行文件时 IJG 署名与改动说明义务依然存在；
3. 以当前仓库为准：GPL 组件清单（如 idct_mmx.c）会随代码重构增减，实际生效范围应以 configure 中各组件的 deps 声明和当前文件树为准。

理解这套体系后，你在集成 FFmpeg 时就能回答三个关键问题：二进制能以什么许可分发、哪些功能（GPL 滤镜、x264 编码器、FDK AAC）在当前构建中可用、以及哪些外部库组合会触发 --enable-version3 或让产物变为不可分发。