近日，一则关于 Voice. AI 从 Discord 服务器窃取开源代码，并拉黑质疑者的消息在网络上持续发酵。
Voice.ai 是一个语音转换 SDK 的开发商，他们还在多个平台上开发了类似的应用。
违反开源协议被发现，当事人“拉黑”质疑者
一位名叫 Ronsor 的软件开发兼安全研究员称，该公司的软件违反了其库中的两项开源许可（ GPL 和 LGPL 协议）。
据 Ronsor 的博文介绍，他在扫描该公司的 Windows 应用时发现其中包含两个第三方组件 Praat 和 libgcrypt，它们被静态链接到 VoiceAILib.dll 库中。也就是说，该公司在其专有软件中集成了开源语音分析软件 Praat 和密码库 libgcrypt 的代码，而没有发布其软件的源代码或提供适当的归属。
为了证明 Voice.ai 的应用包含与 Praat 库基本相似的代码，Ronsor 发布了该应用的反编译源代码，以方便与库中的函数进行比较。反编译 VoiceAILib.dll 后，Ronsor 发现很多函数与 Praat GitHub 存储库中的代码相匹配。
Ronsor 反编译的代码：
原始代码：
这是令人担忧的，Praat 是根据 GPLv3 获得许可的 ，而 libgcrypt 是根据 LGPLv2.1 获得许可的，这些许可证根本不包含在软件中。
事实上，Voice.ai 在不遵守服务条款的情况下 违规打包了开源库， 该公司的服务条款 禁止复制、修改和重用该软件，这违反了提供这些自由的开源许可。Voice.ai 许可声明摘录：
我们保留对 Beta 产品的所有权利、所有权。你同意 Beta 产品仅供个人使用。你不得将 Beta 产品或其任何部分或组件 出售、转让、转让、质押 或以任何方式阻碍或转让给任何第三方，或以任何方式使用它来生产、营销或支持您自己的产品。你不得向任何第三方复制、出售或营销 Beta 产品；修改、再利用、反汇编、反编译、逆向工程或以其他方式翻译 Beta 产品或其任何部分。
Ronsor 还质疑称，该应用大量使用了混淆技术和它收集的数据，其中包括：主板和 CPU 信息、音频接口、操作系统版本、启用的网络接口、IP 地址和 MAC 地址、电脑主机名和 Voice.ai 安装路径。
“虽然其中一些信息在调试或其他方面有明显的合法用途（如音频接口、操作系统版本、安装路径），但其他信息，如计算机主机名和网络接口元数据，则与 Voice.ai 的主要功能完全不相关，”他说道。
Ronsor 认为，这些信息被发送到 Voice.ai 的服务器，在那里使用 API 生成通信加密。他还谈到，在 Discord 上的讨论中，有其他人指出，该代码包含虚拟机检测例程——可能是一种反取证技术。
Ronsor 观察到，“因为这个‘数字版权管理间谍软件’，我们无法离线运行 Voice.ai 的软件。虽然在技术上，这显然是可行的，因为它使用本地 GPU 来进行实时 AI 处理”。
在发现了诸多端倪后，Ronsor 表示他曾于 2 月 1 日试图通过 Discord 聊天工具联系 Voice.ai 公司，并在第二天通过电子邮件再次联系了他们，希望公司了解到他对违反许可的担忧。
但令人失望的是，因为他带来了麻烦，2 月 4 日，他被 Voice.ai 的 Discord 服务器封杀了，显然是这为了规避 DRM（数字版权管理）讨论。
Ronsor 表示他没有收到任何版主或开发人员的警告，而且在登录服务器期间他发送的消息少于 10 条，因此，他不相信我违反了任何合法规则。
截至 2 月 6 日（周一），他还没有收到该公司关于他的软件许可问询的答复。
删除代码了事？
当地时间 2 月 7 日，外媒 The Register 联系了 Ronsor，他说：“我还没有直接收到 Voice.ai 的回复。不过，他们 Discord 的版主公开表示他们已经通知了开发者，而开发者（应该）正在与他们的法律团队进行沟通。”
随着事情不断发酵，Voice.ai 坐不住了。
Voice.ai 开发人员完全坚持他们的软件根本不是恶意软件，但来自防病毒软件的广泛警告确实引发了一些问题。
2 月 8 日，Voice.ai 在接受 The Register 采访时表示，关于代码不当使用的说法是不实的，但该公司也承认，其软件包含了一些开源库，并且，在目前正在测试的更新中，他们删除了遵循 GPL 许可的代码。
Voice.ai 似乎也比较愿意友好地解决这个问题。该公司发言人于 2 月 9 日回复说，公司正在调查 Ronsor 的说法。
“我们注意到，最近有关于我们涉嫌不当使用开源代码的猜测。我们会非常严肃地对待这种性质的指控，我们明确声明，这些指控是虚假的，”该公司发言人在一份电子邮件声明中表示。
“我们的技术支持团队在 2 月 2 日晚上收到了来自用户 @ronsor 的源代码请求。我们的团队处理了大量的客户问询，因此，在 2 月 6 日即两个工作日后才得以处理这个请求。而此时，该用户已于 2 月 4 日发表了一篇博文，并开始在公共平台上提出指控。”
“与此同时，该用户加入了我们的公共 Discord 服务器，并参与了有关如何违反产品服务条款的对话，比如逆向工程，这导致我们的志愿者社区版主对其进行了封杀。这与源代码请求完全无关，当时没有人知道这一点，尤其是我们的 Discord 审核团队。"
“作为一家以人工智能民主化为使命的初创公司，我们支持开源要求，完全遵守所有的开源许可。我们正设法尽快回应相关请求。我们对 @ronsor 的告知和请求表示感谢。”
“虽然我们的绝大多数代码都是由 Voice.ai 开发的闭源代码，但我们也包含了一些开源库。我们软件的核心技术并不依赖于这些库来实现。方便起见，我们将在 Github 存储库中提供相关源代码。而为了消除疑虑，我们删除了遵循 GPL3 的代码，并且几个小时内就完成了，这正是因为它只是作为一个最小的非核心功能。一旦 QA 审核通过，我们就会推送这个更新。”
“我们希望这最终会强化我们与开源社区的关系，并在此感谢 Discord 会员的支持。”
有更多细心的网友深挖后发现，Voice.ai 还违反了除上述两条许可外的其他开源许可，包括但不限于 libFLAC 的许可和 OpenH264。这些许可证需要署名，但在 Voice.ai 的代码中均没有给出。
2023 年 2 月 14 日，Voice.ai 开发者发布 0.1.26.1，似乎移除了 Praat；但是，它仍然包含 LGPL 的 libgcrypt，并且它们仍然违反其开源依赖项的许可要求。此外，他们还没有发布 0.1.25.1 的代码。
2023 年 2 月 17 日，随着 0.1.27.1 的更新，Voice.ai 开发人员终于将 libgcrypt 移到了自己的 DLL 中，并包含了其开源依赖项的许可证。不过，他们还是没有发布 0.1.25.1 的代码。
“希望这些违规行为是出于无知，而非恶意”
The Register 就该事件涉及的一些开发者关心的问题对 Ronsor 进行了提问。
考虑到历史上和现实中开源社区对法律挑战的厌恶，你是否认为社区压力是处理所谓的开源许可违规的最佳方法？
Ronsor：“如果没有证据证明是明显的恶意行为，我认为社区压力应该永远是第一选择，如果开发商遵守了许可，那么过去的违规行为就应该得到谅解。奖励良好行为很重要。如果向开发商施压无效，那么威胁采取法律行动就成了唯一的选择，还应该寻求金钱赔偿，因为诉讼需要花费时间和金钱，起初调查违规行为也需要花费时间和金钱。”
Ronsor 说，在很大程度上，他赞成自由软件基金会在这个问题上的执行原则。
Ronsor 坦言：“虽然我被 Voice.ai Discord 封杀了，但我仍然希望这些违规行为是由于无知而不是恶意。毕竟，许可很复杂。”
在开源圈里，窃取开源代码、违反开源协议的事件屡见不鲜。在社区开发者看来，这种短期投机、违反道德的行为是不可能取得成功的。
一位曾经在 Facebook 工作的开发者表示：“即使忽略与此类问题相关的法律或道德问题，如果有人窃取 GCC 并尝试将其作为自己的产品进行营销，那么他其实是在销售已经免费的产品。不太可能成为成功的商业策略，现在销售的大多数软件都是卖给企业的，即使是一丁点的许可证问题也足以扼杀特定产品的市场。”
此外，一位曾经在微软工作过的网友表示：“我记得我在 Microsoft 的第一天，我的开发经理告诉我在 Microsoft 编写代码的一条基本规则——永远不要在网络上查找任何可用的开源或第三方代码。就算单纯为了好玩儿也不能去这么做，因为你永远不知道你会下意识地复制哪一个。”
声明：本文为 InfoQ 翻译 整理，未经许可禁止转载。
参考链接：
https://www.theregister.com/2023/02/08/voiceai_open_source
https://undeleted.ronsor.com/voice.ai-gpl-violations-with-a-side-of-drm/
加V：busulishang4668
腾讯云云原生提质增效实践精选集 2024
《2024腾讯云云原生提质增效实践精选集》出炉，5大热门技术领域，13个行业精选标杆案例，痛点到解决方案全...
评论