按此：您的 WordPress 插件是否兼容 GPL？

欢迎来到 Press This，WMR 的 WordPress 社区播客。 每集都有来自社区各地的嘉宾，并讨论 WordPress 开发人员面临的最大问题。 以下是原始录音的转录。

由红圈提供支持

Doc Pop ：您正在收听 Press This，这是 WMR 上的 WordPress 社区播客。 每周我们都会重点关注 WordPress 社区的成员。 我是你们的主持人，波普博士。 我通过在 WP Engine 中的角色以及对 TorqueMag.io 的贡献来支持 WordPress 社区。 您可以在 RedCircle、iTunes、Spotify 或您最喜欢的播客应用程序上订阅 Press This，也可以直接从 WMR.fm 下载剧集。

如果您曾经为开源项目做出过贡献，您就会知道这一切都与协作和创新有关，但是许多开发人员在确保他们的插件符合 GPL、GNU、通用公共许可证。 这不仅仅是合规问题。 这是为了维护开源精神。

今天我们有一位特邀嘉宾，Jeff Paul，10up 的开源总监，他将分享他今年在 WordCamp US 上提出的一个改变游戏规则的解决方案。 想象一下，有一个工具可以自动扫描您的代码库，以保证您的插件的 GPL 兼容性，即使您添加新功能和依赖项也是如此。

这就是我们今天要讨论的内容。 但在我们深入探讨之前，Jeff，您能告诉我们您的 WordPress 起源故事吗？

杰夫·保罗：当然。 我不知道我有确切的年份。 大概是2000年代初。 我在以前的 CMS 上有一个个人网站，我想它叫 Geeklog。 加上当时我的托管提供商，以及谁知道还有多少其他因素，CMS 中的内容崩溃了。

所以我当时只是在寻找一些东西来代替它。 我发现 WordPress 可以满足我的需要。 您知道，我自己并没有走上构建 CMS 的道路，这对很多人来说似乎是一个很好的起源故事。 但那是，我不知道，'04 到 '07，在这个范围内的某个地方，但我没有，有点跨越鸿沟做出贡献，直到 WordPress 4.7 版本发布，当时我加入了发布小组海伦·侯桑迪和亚伦·乔宾。 因此，我花了很多年时间成为该项目的消费者，直到相当长的一段时间后，我才成为贡献者，并且从那时起，你知道，我一直在这条道路上继续前进。 嗯，你知道，此时，双重消费者和贡献者。

DP ：您也是 WordPress 核心的非常积极的贡献者。 10up 在插件存储库中维护了数十个插件，包括 ElasticPress、Distributor、ClassifAI。 这些都可以在 wordpress.org 存储库上找到，并在 GitHub 上公开并使用开源实践进行维护。

您对我们将要深入探讨的主题非常熟悉。 为什么我们不从 WordPress 存储库（例如 WordPress 插件存储库）开始呢？ 快速告诉我们，什么是 WordPress 存储库以及向其上传任何内容的规则是什么？

JP ：当然。 因此，WordPress 存储库由开源项目 WordPress.org 托管，与 WordPress.com 分开，与生态系统中的任何其他主机分开，与第三方插件公司或分销商分开。 它是直接链接或绑定到每个 WordPress 安装的内容。 当有人在 WordPress 管理员中搜索插件或主题时，这些搜索是通过 WordPress 管理员中提供的 WordPress.org 插件存储库和主题存储库进行的。 WordPress.org 上也是如此。 实际上，那里提供相同的搜索、相同的内容。

就列出其中的内容而言，wordpress.org 插件审查团队为插件开发人员提供了一套详细的注意事项指南。 然后有一个实际的提交工作流程来完成向 wordpress.org 插件存储库的初始提交。 一旦获得批准，就会为您的插件创建一个 SVN 存储库。 而且，您知道，任何更新、发布等都会推送到 SVN。 这就是目前所有可在 WordPress.org 或 WordPress 管理员中搜索的内容的生存和呼吸之处。

DP ：我认为首要规则之一是，您放入 WordPress 存储库的任何内容都需要符合 GPL，包括字体和图像，而不仅仅是代码。 那是对的吗？

JP ：正确。 正确的。 因此，从字面上看，插件团队的第一条规则是插件整体必须兼容 GPL。 这与 WordPress 遵循的许可证相同，正如您提到的，代码、图像和第三方库都必须兼容 GPL。 它不一定是实际的，你知道，GPLv2 许可证，还有其他与 GPL 兼容的许可证，但是，是的，字体、图像、第三方库、依赖项，所有这些都必须与 GPL 兼容，而不仅仅是插件开发人员编写的代码，对吗？ 所有其他的东西也需要兼容 GPL。

DP ：为了不让听众等待，我们可以直接跳进去。 您的演讲是关于如何使用 GitHub 操作检查 GPL 兼容性。 您能引导我们完成这个过程吗？

JP ：是的，这在一定程度上源于我作为 10Up 开源总监的角色。 您知道，单个插件甚至多个插件的日常插件作者可能不会意识到这一点，或者不会打扰他们。 但我认为在某些时候，我几乎在半夜醒来，想，“我不知道我是否确定你知道，所有的图像，所有的第三方依赖项，所有的字体等等，都是 GPL 兼容的，并试图在 10up 中为我们找到一种大规模的方法，就像您提到的那样，我们有数十个插件可以在 wordpress.org 存储库或 GitHub 上找到。 源头在那里。

我不想仔细梳理所有这些内容，也不想检查我们用于插件的任何上游依赖项，并弄清楚这些是如何获得许可的。 对于单个插件来说这可能是一件痛苦的事，更不用说多个插件了。 通过一些在线搜索，我发现有一些工具、一些 GitHub 操作可以用来帮助有效地自动化该过程，这样，你知道，不仅仅是对存储库进行一次一次性扫描就可以说，是的，你兼容或不兼容，你不兼容，但继续扫描，以便任何未来的错误修复、增强等，这可能会添加新的依赖项，或者可能会在插件中增加依赖项，而这可能会改变某些东西的方式获得许可，能够检查正在进行的情况，并进行这种首次通过是我试图弄清楚的事情，这样它就不会成为一个手动的、密集的过程，并且有点像一场持续的噩梦，以确保，即兼容性。

所以，是的，我的意思是，我认为我最初担心的是，我不知道 — 我无法知道我们添加的某些功能（如果我们包含新的依赖项）与 GPL 兼容，然后意识到可能存在更糟糕的情况，即我们已经发布了插件，并对其软件中已经存在不兼容性的情况进行了迭代。

这就是我想尝试解决的第一个问题。 第一次初始扫描，对吧？ 您知道，我们的各个插件以及 10up 支持的所有插件是否真正与我们声明的许可证兼容？ 希望他们是这样。 然后，你知道，从那里开始，持续检查确保未来的 PR，无论是来自我的团队还是 10up 的开源实践，广泛地与其他 10up 为项目做出贡献，或者只是社区中的任何人，确保这些保留了我们在插件本身中声明的许可。

DP ：只是为了在这里澄清一下，如果你没有，如果你通过这个发现，存在，呃，一些现有的依赖关系或其中的某些东西，这是不合规的，那么后果就是某种羞辱或者您是否因不遵守规则而可能遭受惩罚性损害？

JP ：所以我不是律师，对吧？ 所以，你知道，我没有律师资格来发表此评论，所以，你知道，这不是有效的法律建议，而是我在插件上运行这些扫描时所采取的方法，因为同样，我没有我知道，我实际上很紧张运行所有这些，不知道结果会是什么。

我的计划是，如果我发现有一个插件正在使用不兼容 GPL 的东西，那么最好的方法是删除该依赖项，将其换成其他东西，有效地清除它，无论问题是什么很快就发布了新版本，对吧？

对于已经出版和发布的内容，我觉得没什么可以做的。 从我的角度来看，这一切都不会是故意规避许可的。 你知道，这只是在某个时刻出现的人为错误，有点类似于向插件作者报告的安全问题。 就像，最好的方法是进行补救并快速发布版本，以便那些保持插件最新状态的人处于更安全的状态，无论是安全问题还是在这种情况下，许可问题。 当然，如果碰巧有一个插件能够产生显着的收入，并且如果可能有的话，有理由表明拥有某些未授权的东西是一个已知的错误，除此之外，我不相信该领域的任何人是故意这样做的，但我认为唯一可能面临法律风险的是那些能显着创收的项目，这将是许可的目标。

所以，是的，我认为长话短说，如果有人运行扫描并在现有代码库中发现问题，我认为最好的方法实际上是发布一个版本，一个更新版本，你知道，在更改日志中调用，在发行说明中指出更改的内容和原因，并对此保持透明。 但在这一点上，我认为插件作者在这种情况下能做的就是最好的事情。 幸运的是，对于 10up 的插件来说，我们没有遇到这种情况。 幸运的是，一切都是兼容的，我希望绝大多数沿着这条路走下去的人，设置一些自动化来给他们带来那种程度的舒适感，能够有类似的体验。

等待 GitHub 操作运行几秒钟或一分钟可能会有点紧张、焦虑。 但是，你知道，一旦一切都过去了，我想大多数人可能最终都会陷入这种状态。

DP ：说到舒服，我们要短暂休息一下。 因此，请坐下来放松一下，短暂的广告休息后，我们将回来对 10up 开源计划总监 Jeff Paul 进行更多采访，内容涉及如何保持插件符合 GPL 规定。 短暂休息后，请继续关注更多内容。

DP ：欢迎回到 WordPress 社区播客 Press This。 我是医生。 我正在与 Jeff Paul 讨论如何使用 GitHub 操作来确保您的代码、插件符合 GPL 规定。 在休息之前，我们对此进行了一些深入探讨，并讨论了如果您不完全合规的后果。 我想我想回到这个具体的事情上。 任何人都可以创建 GitHub 操作。 但是 Jeff，您在 WordCamp 演讲中提到您使用官方 GitHub 操作，我认为做了一些小改动。 您能告诉我们人们应该寻找能够做到这一点的操作名称吗？

JP ：当然。 这就是依赖性审查操作。 所以 GitHub.com，斜线操作，斜线依赖，连字符审查，连字符操作。 希望抄本能够正确理解这一点。 如果发现任何问题，我确实在我的网站上的一篇涵盖该演讲的帖子上对此进行了注释。 因此，有可用的链接，但如果您在 GitHub 操作市场中搜索依赖项审查操作，您将有望找到我使用的官方链接，它不仅仅是检查插件依赖项。 它不仅会检查许可证。 它还可以检查插件依赖项中的漏洞和其他内容。 但我使用它的唯一目的，也是我使用它的核心目的，是检查插件依赖项中的无效许可证。

DP ：您可以通过此操作设置您想要遵循的 GPL 类型。 您可以包含一个许可证，它会根据该许可证进行检查。 而且，如果您维护数十个插件，您仍然可以获取相同的东西。 您可以将所有这些您维护的插件仍然保存到该目录中，这样您就不必每次都去更新它，对吗？

JP ：正确。 是的。 我看到你在 WordCamp US 上听完了我的演讲，感谢你在观众中清醒地倾听，或者你在 YouTube 或 WordPress.tv 上看到了它，但是，是的，我希望大家有两种标准流程跟随这里。

第一，负责一个或极少数插件的插件作者，或者拥有一对多插件的人，他们有很多支持的插件。 因此，对于只有一个操作的人来说，GitHub 操作（正如您所定义的那样）可以在该工作流程文件中有效地调用依赖项审核操作，并让它扫描您的存储库，有两个环境变量或您可以提供的参数。 该操作之一是允许许可证，其必然结果是拒绝许可证。 你不能同时做这两件事。 我采取的方法是使用允许许可证而不是拒绝许可证。 我的想法是……我宁愿遇到这样的情况：我忘记在允许许可证列表中包含 GPL 兼容许可证，从而得到有效的误报，对吗？ 就像将依赖项标记为与我的许可证不兼容，因为它的许可证只是我忘记添加到列表中的东西，而如果我使用拒绝许可证列表并且我忘记拒绝我不想要的许可证，那么这可能意味着依赖关系将通过，不会被此检查捕获。

因此，我强烈建议您使用允许许可证列表。 如果有人维护单个插件，则只需在工作流程文件中使用该参数和许可证列表。 因此，对于 10up，对于我们的插件，这是 .GitHub 目录，然后是那里的工作流程子目录。 然后我们有依赖项审查工作流程，调用该依赖项审查操作，具有允许许可证列表，您可以在我的网站上提取我的演示文稿或在线查找演讲并查看我们拥有的许可证列表。 您还可以探索 GitHub 上的任何 10up 存储库并查看我们探索的许可证。

我们的工作流程文件有相当详细的记录，并解释了我们如何识别我们认为与我们的插件兼容的许可证。 因此，欢迎人们使用我们拥有的列表，欢迎使用该列表的子集，欢迎人们进行自己的研究，也许可以感受到这种程度的舒适。 但我们确实做了相当长的研究，以确保我们在允许许可证列表中使用的内容实际上与我们声明的内容兼容。 对于 10up，我们几乎默认使用 GPLv2 或更高版本，因此我们列出的所有许可证都与 GPLv2 兼容。

这也是插件作者维护一个插件的情况。 正如您所提到的，对于某人拥有多个许可证的情况，您可以拥有一个单独的许可证策略文件，该文件实际上包含其中声明的所有许可证。 然后，您在插件的工作流程中引用该配置文件、该许可证策略文件，这样，正如您所提到的，您实际上只有一个地方需要维护兼容许可证列表。 如果碰巧有一个新的开源、经倡议批准的许可证恰好与我们兼容 GPLv2，对吗？ 如果有一个新的出现，那么可以将其添加到列表中，或者如果出于某种原因需要删除一个，您不必在数十个位置中执行此操作。 您可以在一个位置执行此操作，然后使用新的许可证列表立即更新引用该配置的所有工作流程文件。

DP ：这都是自动化的，所以如果有人提出拉取请求，它只会为你做。 正确的？

JP ：正确，正确。 因此，当我们在存储库中创建工作流程文件时，我们确实会触发拉取请求。 因此，您也许还可以将其设置为按 CRON 计划运行，您可以让它每周或每月运行一次，但实际上，一旦您执行了第一次运行，您就会扫描依赖项的整个代码库，并且它真的会运行向前，您实际上只需要检查那些传入的拉取请求，如果您没有使用相当严格的系统来要求对插件的默认或稳定分支进行 PR，那么您也可以检查单个提交。

因此，人们可能想要使用其他触发器。 对于 10up，我们倾向于相当严格地要求 PR 来开发和主干分支，以便我们可以可靠地使用此操作，并知道任何引入新依赖项或碰巧更改许可证的版本的依赖项更改都会被此捕获。 所以，是的，我们使用，我们枢转或触发拉取请求，但根据人们的严格程度，您可能会检查对特定分支的个人提交，甚至每天、每周、每月按计划运行，只是知道您的代码仍在通过，没有任何与 10up 的 GPLv2 不兼容的许可证，从而感到安心。

DP ：我们要在这里再短暂休息一下。 当我们回来时，我们将结束与 Jeff Paul 关于 GPL 许可证的对话，并且可能会讨论我们之前没有提到的任何内容。 因此，在短暂的休息后，请继续关注更多内容。

DP ：欢迎回到 WordPress 社区播客 Press This。 我们即将结束演出，我们将稍微调整一下节奏。 最近有一些关于插件存储库审查过程的讨论，基本上只是说明这个事实，它比过去慢了一点。

有些人说他们知道要花几个月的时间才能对某些内容进行审核，而我认为在我使用 WordPress 的大部分时间里，审核时间可能会在四个星期内达到顶峰。 所以，杰夫，我知道他们已经讨论过可能要对此做出一些改变。 您能告诉我们团队现在正在做什么吗？

JP ：当然。 是的。 我已经，你知道，我放大了你所说的话。 我认为从历史上看，我所提交的所有内容都在两周内完成，并且比通常报告的速度要快得多。 大约需要 88 天，这对每个参与其中的人来说都是不幸的。

我认为该团队有一些人员流动。 一些非常有经验的高级知识丢失了。 我认为那些慷慨地介入帮助填补这一空白的人们仍然能够在处理插件和审查那些初始提交方面拥有相同的吞吐量。 他们正在做一些工作来尝试实现其中一些自动化。 因此，您知道，计算机在某些方面可能比人类更擅长，例如运行 WordPress 编码标准以及在报告的真正严重错误的地方进行磨练，对吧？ 不必由人类来检查和处理这些事情，而是拥有一个插件检查器来运行和检查可以自动化的事情，并帮助插件审查团队获得快速的初始暂停，例如，自动通过的事情吗？ 如果是这样，那么，好吧，深入进行人工审查并加快进展速度。 如果事情已经被报告，本质上是自动化的，但没有通过，那么我认为，这是对插件开发人员的更快响应，嘿，我们已经在扫描中识别出这些最初的事情，你知道，请解决这些问题然后提交更新的 zip 文件，让事情回到正轨。

所以我知道他们正在努力添加一些自动化，我认为他们能做的越多来帮助他们走上这条路就越好，只是因为在这一点上，有超过一千个插件，积压很长，而且再次，没有帮助那里的任何人。 所以是的，他们正在研究自动化。 我知道他们想做更多的事情，而且我认为如果这是一个在自动化方面特别有天赋并希望做出贡献的领域，我认为插件审查团队很乐意在这方面获得一些帮助。 因此，如果是这种情况，请务必通过 Slack 进行联系。

DP ：说到联系，如果人们对您在 WordCampUS 上的演讲或 10uP 正在开源领域开展的一些项目有疑问，人们联系您的最佳方式是什么？

JP ：当然。 所以我的网站是 jeffpaul.com。 我的演示文稿就在那里，如果您只是搜索 GPL，无论如何它可能会是第一个帖子之一。 否则，我的电子邮件是[电子邮件受保护] ，我的工作电子邮件，嗯，然后是几乎所有社交网络。 WordPress.org、GitHub、Twitter、slash X，我是@Jeff Paul，你们都可以通过这种方式在社交网络上找到我。

DP ：同样，如果听众想在 GitHub 上找到 10uP 工作的示例，我假设这只是 GitHub 上的 10up 吗？

JP ：正确，是的，github.com/10up。 我们插件的所有存储库都是公开的。 我们的团队密切跟踪新问题和 PR。 这些都通过管道传输到我们的 Slack 频道，因此人们提出的任何问题、任何讨论都可以在那里打开。 我们的团队应该对这些问题做出相当的反应，但如果没有，你知道，在 WordPress Slack 上、通过电子邮件在 Twitter 上联系我，这些都可以。 我总是很高兴与社区中的人们讨论开源问题。

DP ：嗯，非常感谢您今天加入我们，Jeff，与您交谈真是太棒了，我学到了很多关于 GitHub 的拉取请求操作和自动化体验的知识。 这非常有帮助。

如果您错过了上周的 Press This 节目，我们与 Carmen Johnson 讨论了为 MySQL 5.7 生命周期结束而为网站做好准备的步骤，以及如何为 MySQL 8 做好准备。所以这是一个非常好的节目。可以查看一下，我们还有更多。 如果您想查找转录版本，可以在 TorqueMag.io 上找到这些内容。 感谢您收听 Press This，这是 WMR 上的 WordPress 社区播客。 您可以在 Twitter、Torque Mag 上关注我们的冒险经历。

您可以在 RedCircle、iTunes、Spotify 或您最喜欢的播客应用程序上订阅 Press This，也可以直接从 WMR.fm 下载剧集。 我是你们的主持人，人气博士。 我通过在 WP Engine 中的角色来支持 WordPress 社区，并且我喜欢每周在 PressThis 上关注该社区的成员。