GPL 对 javascript 库的限制

小开

您已经将 JavaScript 库分发给了用户; 因此需要遵守 GPL 对分发的要求。这是否要求你分发网站的其余部分是事情变得复杂的地方-我建议你与一个称职的律师谈论你的确切情况，如果你甚至想走这条路线，并记住，这至少违反了许可证的精神，无论它是否违反了许可证的字面意思。

小开

这绝对会变得很复杂。我给你举个例子。如果您正在使用 jQuery 的 GPL 许可证(我知道这是双重许可的，但是让我们暂时忽略它) ，那会怎么样呢。

Google 有一个 jQuery 的公共发布版本(包括其他 javascript 框架) ，它们在 CDN 上发布，例如:
Http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js

所以在这种情况下，你不是那个将 javascript 库分发给用户的人，google 是; -)

请注意: 正如@bdonlan 所描述的那样，只有经验丰富的律师才能真正参与到这件事中来。我提供这个答案只是为了给你可以和律师谈论的事情提供背景。

小开

我不是律师。我和律师们讨论过使用 gPL 和 lgPL 来解释/动态链接到专有软件中的代码。我们都头疼得厉害。问题不仅仅是你是否必须在 GPL 下发布你网站的其他部分。而是一个非免费的浏览器是否可以合法地运行 GPL 代码。

我最好的非法律建议是永远不要尝试在 Javascript 代码中使用 GPL。我从来没有在 GPL 下发布过 Javascript 库，如果我发现了一些我想要使用的代码，我会尝试让作者给我一个异常。LGPL 也许吧是一个更好的选择，但是这个许可证太复杂了，我建议也避免使用它。

FSF 在他们的常见问题如果一个编程语言解释器有一个与 GPL 不兼容的许可证，我可以在它上面运行 GPL 覆盖的程序吗？中为您提供了答案。令人沮丧的是，这个答案本身是模棱两可的，但它提供了可以在非 GPL 浏览器中运行 GPL 代码的路径。你可能也会觉得 FSF 的文章《 Javascript Trap 》很有趣，尽管它并没有给出你问题的明确答案。

对于上下文，它有助于记住 GPL 和 LPGL 是在 Unix 时代编写的，当时大部分内容都是静态链接的。没有动态链接，没有脚本本身被认为是有价值的知识产权的解释语言，等等。

小开

为了火上浇油。

阅读 gpl v3可以清楚地看到，如果包含了 gpl 的作品，则需要在文件顶部提供源代码和许可文本以及版权声明。

因此，如果我从文件中删除注释和空格并缩短变量名，然后将其“分发”到某人的浏览器(当然是以源代码的形式) ，我可能就违反了许可。顺便说一句，解决方案可能是一个二进制 uuid，它代表损坏文件的适当许可证。有什么想法吗？

如果我使用带有 gpl stmt 的库来提供库的源代码和我自己的“源代码”，那么将它发送到浏览器是否构成免费提供源代码？

我认为这里有足够的漏洞使得许可证无法执行。

我的两分钱/不是律师。

小开

这家伙写了一篇文章: Http://stuck-in-windows.blogspot.com/2009/02/fud-over-javascript-and-gpl.html

在他的文章中，他引用了 gnu 网站常见问题的问答:

(Q)一家公司正在运行一个修改过的 GPL 程序 GPL 是否说他们必须发布他们修改过的资源？

(A) GPL 允许任何人制作修改后的版本并使用它这家公司正在做的是特殊情况。因此，该公司无须释放经修改的源。

常见问题，然后参考的 GNU Affero GPL，这确实需要发布所有网站的源代码。

小开

例如 Magento 使用 GPL v3下的 ExtJS。现在，当 Magento 被购物商店店主下载并安装时，你的意思是商店店主必须连同他们的产品一起给他们的“整个网站来源”一个链接？哈哈

所以在我看来，使用 GPL v3授权的 Javascript 库对任何项目都有好处，除非你试图修改 Javascript 库并将其商业化或相关的商业服务出售。

小开

你的应用程序 + GPL 的库 + 发布-> 开源的 GPL 的应用程序。

这是 FSF 和 GPL 的意图，它适用于任何您正在使用的编程语言。

一个 GPL 的 JavaScript 库会感染你所有的 JavaScript 代码。可能不会影响 HTML、页面内容或服务器端代码。

因此，如果你打算将 JavaScript 库作为一般用途，请不要在 GPL 下发布它们。