Web applications 使用定制版本的GNU/GPL web应用程序作为订阅费商业模式

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

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

---

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

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

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

Flash，因为它被提到了：看起来二进制文件将被分发，因此您修改过的源代码必须在GPL下发布

客户端Javascript：用例似乎包含分发，因此任何代码都需要在GPL下发布。显然，代码正在发送到web浏览器，因此它是可用的，但您可能会混淆发送到web浏览器的代码，在这种情况下，GPL强制您分发未混淆的版本

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

服务器端javascript：（不常见，但为了避免混淆，值得澄清）未分发，所以不需要提供源代码

html和css：我认为这些将属于GPL，您需要在分发它们时提供“源表单”

---

请注意，AGPL实际上/最初的目标是迫使人们在PHP和类似情况下发布源代码，在这些情况下，有大量的服务器端源代码，人们不必发布（称为“软件即服务”案例）。

退几步，很明显，您正试图停留在许可证的边界之内，而完全忽略甚至撕碎许可证的精神和意图

这是一件坏事。你将在律师身上花费大量的时间和精力，以确保你刚好在限额内，你将不得不为诉讼风险留出大量的资本准备金，以防其他人找到解释许可证的方法，使你站在错误的一边，在你努力保持（公正）（勉强）合法的过程中，你将受到律师的控制

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

---

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

用户如何与游戏互动？如果GPL部分是例如Flash，那么您正在分发二进制文件，因此您可能需要提供源代码。如果都是服务器端的话，可能不是。Flash可能很棘手。是的，但是为了简化问题，让我们假设没有Flash，只有PHP/HTML/CSS/JS。虽然我担心后三个问题实际上是分发给客户端的，但只有PHP是服务器端的。我投票结束这个问题，因为它是关于许可或法律问题，而不是编程或软件开发。关于细节，以及更多内容，+1，AGPL的基本原理明确指出GPL没有施加此类限制。如果我没有提出太多要求，请您对“基于web的服务不需要提供GPL或LGPL代码的任何衍生产品”部分进行一点扩展。如果可能的话，提供一些值得信赖的参考资料或文章？我担心HTML/CSS/JS实际上正在离开服务器，因此应用程序不完全是服务器端（内部）。创建AGPL的全部原因是为了解决GPL和LGPL在基于web的服务方面存在的漏洞。GPLv3的第1条规定：“相应的源不需要包含任何用户可以从相应源的其他部分自动重新生成的内容。”。这可能（IANAL）可以解释为PHP生成的HTML、CSS和JavaScript不被认为是源代码的一部分；不过，这可能不包括单独文件中的HTML、CSS和JavaScript。