作者 | 李冬梅、平川
近日,一则关于 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/
https://www.quora.com/Why-don%E2%80%99t-people-just-steal-open-source-code-do-a-quick-restructuring-and-sell-it-commercially-as-their-own-Is-there-a-way-to-prove-if-you-think-someone-is-using-your-OS-code-in-a-closed-source-code-format-for-profit
本文转载来源:
https://www.infoq.cn/article/PgmrICihkXIYCPc7cqyw