Mercurial进程中的钩子，GPLv2 +“派生的工作”与否？

Question

我想将Mercurial用作封闭源商业产品的一部分。我知道我可以使用Mercurial的命令行界面，并且可以在不违反GPLv2 +许可的情况下为钩子提供脚本。我可以在不违反许可的情况下使用进程内挂钩吗？

如果我正确理解系统，Mercurial会在hgrc中获取模块名称，然后在运行时链接该模块。这仍然被认为是使用“外部接口”而不是“派生工作”，因为Mercurial链接在我的钩子中，而不是Mercurial中的钩子链接？

Answer 1

Mercurial维基建议扩展计数为派生作品：https://www.mercurial-scm.org/wiki/License#What_is_a_.22derived_work.22.3F_Is_an_extension_a_derived_work.3F

进程间挂钩是链接的，在这种情况下是一个无方向的动词，所以我认为进程中的挂钩也很重要，但我绝对不是专家。

正如theg wiki所指出的，只有法院可以肯定地说，但是像Kiln这样的主要Mercurial项目已经设法打开了所有分布式扩展。

另一种选择是使用新的（Summer 2011）Mercurial功能Command Server，它允许第三方软件与Mercurial进行交互，而无需为每个命令启动新的Mercurial和Python进程。

Answer 2

使用某个API不会强制您采用API的许可。 GPL对GPL许可代码的重新分发和修改进行了限制。只要您分别分发您的分机或挂钩，就没有理由它应该拥有GPL许可。它使用Mercurial API，但它不是派生的工作（修改Mercurial源代码）。

请参阅GPLv2许可证的以下部分：

  

如果该工作的可识别部分不是来自   程序，可以合理地认为是独立和独立的   如果本许可证及其条款本身不适用，则不适用   当您将它们分发为单独的作品时，这些部分。但当   你分发相同的部分作为一个整体的一部分是一项工作   根据该计划，整体的分配必须在   本许可证的条款，其对其他被许可人的权限延伸至   整个整体，因此无论是谁，每一部分   写下来了

另外在旁注中，我怀疑在公司内使用内部修改的Mercurial会算作分配。 （但不要相信我的话:)。

Answer 3

我的个人解释（IANAL）是进程内钩子总是派生的作品，因为它们的定义依赖于Mercurial内部API。如果你打破了与VCS无关的Python脚本和一个调用第一个脚本的瘦Mercurial特定钩子的钩子，你可以保持VCS不可知脚本的闭源，但钩子本身仍然需要是GPL。