求助： mpv 在 GPLv3 下的分发

[blackantt]

项目的客户端需要使用 mpv ，如果各客户端直接从 github 上下载，倒好，问题是 国内访问 github 不稳定；那如果把 mpv 放在 cloudflare 等 OSS 上分发给客户端，是否又需要附带对应的源码？

但是现在根据 mpv-winbuild-cmake 构建 mpv 一直失败。

fable 5.1 max 给的回复：

你圈出来的 https://github.com/mpv-player/mpv/releases 的 "Source code (zip/tar.gz)" 只是 mpv 这一个仓库在 v0.41.0 标签处的快照，几 MB 。而任何一个 Windows 的 mpv.exe 都是静态链接的整体，里面塞着 ffmpeg 、libass 、libplacebo 、x264 、dav1d 、OpenSSL 等几十个库，我们这次的 mpv.exe 有 130 MB ，绝大部分体积就是这些库。

GPLv3 第 1 条把"对应源码"定义为：生成、安装、运行这份目标代码所需的全部源码，包括静态链接进去的库和构建脚本。第 6 条 (d) 要求我们在提供二进制的同一处提供这份对应源码。所以"对应源码"指的是能重新编出这个 exe 的那一整套东西，不是 mpv 自己的源码。一个链接到 mpv 仓库快照的说明，只覆盖了其中一小块，不满足条款。有没有改代码在这里不起作用，只要是我们向用户分发这份二进制，义务就在我们身上。

那为什么不能把别人的二进制连同"完整源码"一起放 R2 ？因为拼不出来。图里官方 CI 产物和 shinchiro 的构建都是在 CI 里当场拉依赖，ffmpeg 、libplacebo 这些走的是移动分支，具体用了哪个 commit 只存在于当次的 CI 日志里，没有人替那份二进制打包过对应源码。这次自建的对应源码包有 56,117 个文件、1.06 GB ，就是因为它把每个依赖的源码树钉在了实际编译用的那个 commit 上。

真正能免掉义务的只有一条路：客户端直接从上游自己的地址下载，例如图里 GitHub 那个 mingw32 zip ，这样分发者是 mpv 项目而不是我们。它的代价你之前也问过：国内访问 GitHub 不稳定，这正是我们用 R2 的原因；而且我们同时需要 ffmpeg 和 ffprobe 做导出，官方 mpv 构建明说没有编码支持，原来的 gyan ffmpeg 又有同样的源码问题。所以一次自建把 mpv 、ffmpeg 、ffprobe 三个二进制和 Vulkan 加载器一起解决，源码、配方、构建日志都在自己手里，也顺手加上了导入表守门。

一句话：自建不是因为改了 mpv ，而是因为要在同一处交出"能重新编出这份 exe 的全部源码"，而别人的 exe 交不出



看不懂。claude 是否有点谨慎做过头了？

[tomchen]

这和你从 github 还是 cloudflare 上下载没关系吧。只要只是 spawn mpv 的编译好的二进制，而不是作为 lib 去 link 或者用它源码，那 GPL 就不会传染你的代码

[zengxs]

mpv 可以 LGPL-2.1 动态链接分发吧，只要你不开那些 GPL 专有的特性就行了

大部分解码库应该 LGPL 就能满足了，少数高性能编码库可能要 GPL

[blackantt]

@tomchen , @zengxs AI 回复: 一句话归纳：两句话谈的都是"我们的代码会不会被传染"，答案都是不会；而我们真正在花力气解决的是"我们分发 mpv 二进制时欠不欠源码"，这两句都没触及，它才是自建的理由。

[imnotlxy]

@blackantt 既然分发的 mpv binary 是由未经修改的官方代码库编译的，我认为没必要附带源码。如果有人问你要源码的话给他发个仓库链接就行，让他从 GitHub 仓库拉取，也可以把原仓库的链接贴到客户端的某个地方。

[ysc3839]

就我个人印象，GPL 协议不主动分发源码并不是很大问题，没记错的话 Red Hat 都要申请才能拿到源码。

[expy]

没修改过，版权页面附上 license 给一个官方链接就行吧。

[zengxs]

@ysc3839 #5 Red Hat 和这个案例不太一样，他上游的 Fedora ，CentOS Stream 都是完全开源的，理论上可以在特定版本的上游代码完全复刻出 RHEL