使用GNU/GPL web应用程序的自定义版本作为订阅费商业模型

Question

如果我拿一个受GNU/GPL许可证约束的web应用程序，在内部修改它，然后将它用作订阅费业务模型，例如。用户为服务和web内容付费，而不是为软件本身付费，因此我不是在分发软件本身，我的自定义软件版本是否受GNU/GPL条款的约束，即重新分发源代码和相同的条款？

为了更深入地了解这个问题，让我们以例如。在GNU/GPL下授权的web游戏。如果我使用它并修改它，然后添加内容和自定义游戏等等，然后用订阅费或免费但游戏内购买的模式托管游戏。在这种情况下，用户将为使用在线服务/服务器和游戏/内容的服务本身付费。我的自定义游戏是否会侵犯原始源的GNU/GPL许可模型，并被要求在相同的条款下发布修改后的源？

至于为服务收费而不是为软件本身收费的基于订阅的商业模式，我知道它并没有侵犯GNU/GPL模型，因此完全有可能，除非有人反驳我？因此，我对问题的源代码发布部分更感兴趣。

Answer 1

商业使用不会以任何方式侵犯GPL。此外，基于web的服务不需要提供任何GPL或LGPL代码的派生代码；只有在基于web的服务中使用的AGPL代码的派生代码必须发布。

Answer 2

让我们看看每种类型的内容：

Flash，因为它被提到了:似乎二进制文件将被分发，因此您修改的源代码将不得不在GPL下发布。

客户端Javascript:用例似乎包括分发，因此任何代码都需要在GPL下发布。显然，代码无论如何都会被发送到web浏览器，所以它是可用的，但您可以对发送到web浏览器的代码进行混淆，在这种情况下，GPL要求您分发未混淆的版本。

php:不是分布式的，所以不需要提供源代码

服务器端javascript：(不常见，但为了避免混淆，值得澄清)不是分布式的，所以不需要提供源代码

html & css:我认为它们属于GPL的范畴，您需要在分发它们时提供“源表单”。

请注意，AGPL实际上/最初的目标是迫使人们在PHP和类似的情况下发布源代码，在PHP和类似的情况下，有大量的服务器端源代码，否则人们就不需要发布(称为“软件即服务”情况)。

Answer 3

退后几英尺，很明显，您试图停留在许可证的文字范围内，而完全忽略，甚至撕碎许可证的精神和意图。

这是一件坏事。你将在律师身上花费大量的时间和精力，以确保你恰好在限制之内，你将不得不为诉讼风险留出大量的资本储备，以防其他人找到一种方法来解释许可证的字母，这会让你站在错误的一边，你将在努力保持(刚刚)(勉强)合法的过程中受到律师的控制。

这对你的业力也是非常不利的。

为什么不花费额外的精力，编写自己的游戏，并随心所欲地许可它呢？我意识到这是更多的工作，但我在第二段中概述的项目都变得不那么重要了，而且你不会收集业力上的黑色污点。