正确的方式销售商业产品的小脚本在它是GPL？

Question

我正在开发一个商业CMS，我要出售。我使用jQuery，也使用日期和时间选择器jQuery插件，我可以说这只是我的大脚本的1%。

我不想出售我的整个程序作为GPL，因为这两个小的集成(jQuery和DateTime选择)。

我的问题：

1. 我很担心执照的问题。什么是销售我的产品最好的方式(什么应该是许可类型)？
2. 有没有办法提供部分许可？我的意思是在我的许可证中添加一个小通知，说明jQuery和DateTime选择器仍然在GPL中，但是对于这个CMS的另一部分来说，它是一个商业许可吗？
3. 如果没有任何方法销售商业产品作为接近的来源与GPL小零件，什么是最强大的许可证出售我的产品，以确保它的安全？

Answer 1

简而言之:不，不能在同一个脚本中包含GPL和非GPL代码。

长话短说:是的，但前提是你清楚自己在做什么，而不是破坏GPL的精神。我的理解是：

如果您将GPL许可的东西合并到您的软件中，那么这些部分必须在GPL下保持许可。方法:你必须向任何有要求的人提供这些“模块”的副本。如果您修改了它们，则必须提供已修改的副本。最后，在分发应用程序时，必须包括应用程序的这些部分的GPL副本。我曾与一些人说过，如果您使用GPL许可软件，您的整个应用程序默认为GPL许可证，这是一个小误解。这不是真的。

GPL有几个值得注意的例外。如果您在一个单独的过程中运行软件，它将构成一个单独的程序。这里的含义是，您可以与不受GPL绑定的GPL软件接口，只要交换仅限于消息传递(IPC)，而不是直接链接(更新PC和跳入GPL域)。运行GPL软件的服务器的客户端不受GPL的约束。通常，属于软件作品本身的版权(而不是EULA)许可不能涵盖其应用的程序的输出。

此外，GPL允许聚合工程。聚合工程包括在GPL-v3第5节中：

将涵盖的作品与其他独立和独立的作品进行汇编，这些作品本质上不是所涵盖作品的延伸，也不是与其结合在一起的，例如在存储或发行媒介的一卷内或上形成一个较大的程序，如果汇编及其由此产生的版权没有用于将汇编的用户的访问权限或合法权利限制在个人作品允许的范围之外，则称为“聚合”。将涵盖的作品包含在聚合中并不会导致本许可证适用于聚合的其他部分。

请注意，聚合工作并不指与GPL组件链接的软件。正如GPL明确指出的那样，如果发生了与GPL覆盖的软件的任何链接(除非LGPL或系统库异常等显式链接除外)，那么客户机工作就变成了GPL。因此，如果代码在同一个二进制文件中结束，或者运行在同一个进程中，从而直接调用公开的函数，则通常必须遵循GPL。

这才是有趣的地方。我不知道这是否会在法庭上站得住脚，但根据我的解读，一个GPL组件和一个非GPL组件可以在同一个进程内执行，只要其中一个不直接调用另一个进程，这似乎是合理的。换句话说，如果它们只共享一个数据模型，我相信它们可以共存。无论如何，在两个这样的组件之间画一个硬的进程边界从来都不是一个坏主意。

例如，粘度是为聚合OpenVPN客户端提供配置接口的VPN应用程序。粘度的用户界面不包括在GPL中，因为它只是为OpenVPN生成配置数据，不链接到OpenVPN，也不做任何其他事情，只是(指示系统)调用整个二进制文件。然而，为了使集成更加平滑，粘度也推出了补丁版本的OpenVPN。它们应用的补丁以及由此产生的从OpenVPN派生的二进制工作将在GPL下讨论。

另一条路线是SAAS模型。甚至不要出售软件，而是出售它提供的服务(以及对这些服务的相关支持)。在我看来，这是目前最受欢迎的模式。在这个模型中，您的知识产权(通常是商业模式)不是软件(IP是无关的)。您编写的软件，然后您成为最好的供应商的服务，为您的客户。这就是Github，Bitbucket等人的工作方式。