基于 Electron 框架 (libffmpeg) 的运输应用程序中的法律问题

Question

我们正在电子 v 12.0.7 上构建和部署基于桌面的应用程序。它将是一个（免费）商业软件，部署到全球约 2-3 百万用户。最近，我们的法律团队询问了与 Chromium 捆绑在一起的专有编解码器，我认为确认这一点的最佳方法是联系这里。

因此，以下是我需要帮助的具体事项：

1. 我们是否使用专有编解码器运送铬？如果是，那么在与电子 v 12.0.7 捆绑的铬中默认出现的潜在有争议的编解码器是什么？

2. 是否有关于电子团队如何构建铬（带有哪些标志）的文档？

3. 默认的 libffmpeg.dylib/dll 是否与电子构建 ffmpeg 捆绑在一起，支持 H.264 和 MP3 编解码器之类的东西？

4. 我注意到每个电子版本都有 libffmpeg 二进制文件，例如https://github.com/electron/electron/releases/download/v12.0.7/ffmpeg-v12.0.7-darwin-arm64.zip。这个二进制文件的目的是什么？

任何帮助，将不胜感激。

Answer 1

好吧，我花了一段时间才浏览完所有的信息。我从https://github.com/electron/libchromiumcontent/issues/174#issuecomment-184187254开始，最终在 Electron 的 Discord 服务器上与 Electron 团队的多个人员进行了交谈。我在这里整理我的发现，以便为某人节省一些时间。这是我发现的。非常欢迎任何更正/编辑，以便此处提供的信息正确无误。

1. 我们是否使用专有编解码器来交付铬？如果是，那么与 Electron v 12.0.7 捆绑在一起的 chromium 默认包含哪些潜在有争议的编解码器？

是的。至少在 OSX 上，Electron 默认附带的libffmpeg.dylib包含 AAC 和 H264 的导出符号（用于专有解码器）。因此，它们仍然属于非免版税软件领域。我认为如果您打算将您的应用程序商业化（使用默认的电子+ libffmpeg.dylib），这里需要法律建议

例如，可以使用以下命令查看 dylib 导出的解码器列表：

nm -gU /Applications/{your-app-name}.app/Contents/Frameworks/Electron\ Framework.framework/Versions/A/Libraries/libffmpeg.dylib | grep 'decoder'

我编写了一个简单的 python 脚本来查看任何基于电子的应用程序，并打印 libffmpeg 中可用的解码器列表（捆绑在基于电子的应用程序中）。我的脚本的示例输出：（我的应用程序是使用 Electron v 12.0.7 构建的）

可用/从 libffmpeg.dylib 导出的解码器：['aac', 'aac-latm', 'flac', 'h264', 'libopus', 'mp3', 'pcm-alaw', 'pcm-f32le', 'pcm -mulaw'、'pcm-s16be'、'pcm-s16le'、'pcm-s24be'、'pcm-s24le'、'pcm-s32le'、'pcm-u8'、'theora'、'vorbis'、'vp3 ', 'vp8']

因此，我们基于电子的应用程序默认使用aac和h264解码器（非免版税软件）。据我所知，这些可能会导致可能的专利侵权问题。

2.是否有关于 Electron 团队如何构建 Chromium 的任何文档（带有哪些标志）？

我找不到任何结论性文件，但https://github.com/electron/ electron/blob/58c58c46c4e03c996983a0c71163e1a5efed12fa/build/args/all.gn 提示默认情况下proprietary_codecs在电子的构建中设置为true

3.默认的 libffmpeg.dylib/dll 是否与电子构建 ffmpeg 捆绑在一起，支持 H.264 和 MP3 编解码器等？

看起来确实如此（基于上述）

4.我注意到每个 Electron 版本都有 libffmpeg 二进制文件可用，例如https://github.com/electron/ electron/releases/download/v12.0.7/ffmpeg-v12.0.7-darwin-arm64.zip 。这个二进制文件的目的是什么？

如果您关心运送免版税二进制文件而不是处理专利问题，那么这可能是您应该使用的（除非您选择通过自己调整 gn args 来构建整个电子）。

快速检查这些 ffmpeg.dylib 会发现 AAC 和 H264 解码器不存在（或者至少没有为它们导出符号）。因此，这让我相信这些自定义版本的 dylib 是由 Electron 团队构建的，并牢记了这一点。使用相同的脚本，这是 libffmpeg 自定义版本中可用的解码器列表的输出

可用/从 libffmpeg.dylib 导出的解码器：['flac', 'libopus', 'mp3', 'pcm-alaw', 'pcm-f32le', 'pcm-mulaw', 'pcm-s16be', 'pcm-s16le '、'pcm-s24be'、'pcm-s24le'、'pcm-s32le'、'pcm-u8'、'theora'、'vorbis'、'vp3'、'vp8']

这就是dylib两个版本的区别（左边是从Electron网站下载的，右边是Electron默认自带的） 看来这个问题已经被发现，我们有一个 electro-packager 插件，可以为您完成所有繁重的工作： https: //github.com/MarshallOfSound/electron-packager-plugin-non-proprietary-codecs- ffmpeg

由于我们不使用电子打包器（而是电子构建器），因此我不得不将替换 libffmpeg 的逻辑放在 afterPackHook 中：https://www. Electron.build/configuration/configuration#afterpack

要记住的重要步骤是：需要在对整个应用程序进行代码签名之前完成此替换（否则会破坏代码签名完整性）。

希望它可以帮助其他遇到同样问题的人。干杯!