本月早些时候，我们报道了关于 libogc 的酝酿争议，libogc 是社区开发的 C 库，是 GameCube 和 Wii 自制软件的支柱。关于这个库有多少内容是基于任天堂泄露的信息的问题已经流传了几十年，但最近对 libogc 包含来自其他开源项目的代码而没有适当归属的指控将这场争论推向了高潮——最终导致 Wii Homebrew Channel 开发人员 Hector Martin 归档了这个受欢迎的项目，并使用其 README 作为收集针对 libogc 及其开发人员的证据的中心点。
当时，大多数索赔都与取自多处理器系统实时执行程序 (RTEMS) 项目的代码有关。马丁和社区中的其他人进行了自己的调查，发现两个代码库之间存在一些惊人的相似之处。一位熟悉这两个项目的开发人员甚至表示，libogc 中多达一半的代码实际上是从 RTEMS 中提取出来的，并进行了混淆处理，以便看起来像是原创作品。
尽管其中一些说法包含令人信服的证据，但它们仍然只不过是指控。就 libogc 团队而言，他们否认有任何不当行为。该项目的贡献者解释说，libogc 代码与泄露的任天堂库或其他开源项目之间的任何相似之处都只是表面的，并且是为游戏机等受限系统进行开发的不可避免的结果。
但这一切在 5 月 6 日发生了变化， RTEMS 团队就此事发布了官方声明。事实证明，他们已经关注这一情况有一段时间了，并且对 libogc 代码进行了自己的审计。他们的结论是，不仅 RTEMS 代码在没有归属的情况下被使用，而且似乎至少有一些代码也被从 Linux 内核中逐字复制——这使得许可证纠纷（及其解决方案）变得更加复杂。
宽松与限制
乍一看，这一切似乎都不是问题。毕竟libogc、RTEMS、Linux内核都是开源项目。当然，将这些项目作为开源发布的首要目的是促进甚至鼓励源代码共享。从某种意义上说，这可以被视为系统按预期运行。
事实上，这里真正的问题并不是代码的重用。问题源于各个项目提供源代码所依据的许可证，更具体地说，是这些许可证相互集成的程度。
当投诉称 libogc 使用 RTEMS 的大量代码时，合规之路很简单，因为后一个项目是根据所谓的宽松许可证（即2-Clause BSD License）发布的。顾名思义，此类许可为用户提供了如何重用代码的广泛权利
例如，人们可以采用 BSD 许可的代码，将其按原样合并到闭源项目中，然后在不违反许可的情况下出售生成的软件以获取利润。最初的项目所要求的回报就是您给予适当的归属。在这种情况下，这意味着确认您使用了文档中所述项目的代码，并包含许可证的副本。
回到 libogc，只需向项目的 GitHub 存储库进行一次提交即可解决当前的问题。只需简单说明该项目使用了 RTEMS 的代码和 BSD 许可证副本即可满足要求。坦率地说，面对压倒性的证据表明他们确实重用了代码，libogc 开发人员甚至不会做出如此简单的让步，这是站不住脚的； RTEMS 开发者在声明中表达了这样的观点：
RTEMS 是开源的，这意味着只要满足许可条件并维护版权，就可以复制和使用 RTEMS。我们不明白为什么会删除许可详细信息和版权，并且普遍忽视应用适当的归属。因此，RTEMS 许可证和版权持有者保留与复制 RTEMS 代码相关的权利。
话虽如此，libogc 似乎包含来自 Linux 内核的代码的消息使事情变得相当复杂。与 RTEMS 不同，Linux 是根据 GPL v2 获得许可的——该许可不仅限制性更强，而且本质上是病毒式传播。
内核代码案例
正是许可证的病毒式传播给 libogc 带来了最大的麻烦。如果他们确实使用了 Linux 内核的代码，那就意味着只有两种解决方案。要么必须删除有问题的代码，要么整个项目需要根据 GPL v2 重新获得许可。
对于像 libogc 这样古老的代码库，更改许可证将是一项艰巨的任务，因为向项目添加代码的每个人都必须同意重新获得其个人贡献的许可。 libogc 存储库列出了数十名贡献者，这只是自项目添加到 GitHub 以来的情况。由于似乎没有CREDITS文件列出 Git 出现之前的贡献，因此目前可能无法知道实际有多少贡献者以及他们添加了哪些内容。
因此，libogc 是否使用 Linux 代码的问题对于决定项目如何前进至关重要。 RTEMS 声明没有详细说明这一说法，只是指出“自旋锁实现是直接从 Linux 大约 2.4 或 2.6 版本系列复制的”。果然，当比较最新版本的 libogc 中的spinlock.h文件和linux-2.6.0/include/asm-ppc/spinlock.h时，确实有几乎相同的功能：
也就是说，这可能并不像看起来那么可怕。为了唱反调，有人可能会说汇编代码的简洁本质意味着两种实现之间不可避免地存在一定程度的相似性。当然，惯例只能让你走到这一步。独立地获得相同的汇编代码是一回事，但是当您考虑相同的变量名称和注释时，这种解释变得更难以相信。
接下来是什么？
截至撰写本文时，libogc 项目尚未就此事发表官方声明。在发表本文之前，我们联系了维护者 Dave [WinterMute] Murphy，但他拒绝发表评论，并表示他首先需要与该库的原始开发者 Michael [shagkur] Wiedenbauer 协商。
与此同时，我们在 RTEMS 项目内的联系人表示，他们相信他们有足够的证据，可以在必要时从 GitHub 上删除 libogc。然而，他们不愿意因为一个最终可以通过简单讨论解决的问题而扰乱 Wii 自制社区，这是可以理解的。虽然 Linux 代码的潜在使用确实给整体情况带来了相当大的麻烦，但如果 libogc 项目至少承认 RTEMS 代码的使用并在这么多年之后正确地归因它，那么这至少将是朝着正确方向迈出的一步。
我们将继续关注事态发展，并及时为您提供最新消息。与此同时，我们认为 RTEMS 声明的最后一行很好地总结了整个混乱的最大收获：
我们现在的目标是提供教育，让人们了解 devkitPro/libOGC 项目所从事的行为如何成为不该做的事情的一个很好的例子。
原文： https://hackaday.com/2025/05/14/rtems-statement-deepens-libogc-license-controversy/