我正在开发一个支持插件的应用程序。我想知道我是否可以在应用程序上应用 LGPL，还是 LGPL 仅适用于图书馆？
要点是我希望应用程序大致是 GPL，但这不是在应用程序加载的插件或脚本上强制执行的。但是，GPL 认为插件是衍生作品，因此在这种情况下，纯 GPL 并不好。
目前我一直在考虑 MPL，但它明确指出该许可证将在加利福尼亚州的管辖范围内，这对于欧洲人来说是不可接受的。
如果我想留下一个弱副本，那么对于应用程序的许可证来说，更谨慎的选择是什么。我应该应用 GPL 而非 LGPL 的任何标准例外情况，以及 LGPL 如何适用于应用程序？许可证确实谈到了库，如果我想将它应用于应用程序，这对我来说是相当混乱的。
是的，它可以应用于应用程序。LGPL3 是 GPL + 链接例外，所以它应该适合您的应用程序。OpenOffice 是 LGPL 大型应用程序的一个示例，我相信他们的推理与您的相似。
LGPL 应该适合您的描述。就插件而言，您的应用程序就是库，可以这么说。
如果您仍然想要适用于单个文件的许可证（可以生成衍生作品 - 例如插件 - 只要它们不包含原始文件的任何部分），您可能还需要考虑类似Microsoft Reciprocal License（文中没有提到微软，所以完全可以重用）：
互惠授予 - 对于您分发的任何包含软件代码（源代码或二进制格式）的文件，您必须向收件人提供该文件的源代码以及本许可的副本，该许可将管理该文件。您可以根据您选择的任何条款许可其他完全属于您自己作品且不包含软件代码的文件。
所以它实际上类似于 MPL，但更短、更清晰，并且不依赖于特定的司法管辖区，但有一个例外：
术语“复制”、“复制”、“衍生作品”和“分发”在此与美国版权法具有相同的含义。
但这更像是对重用术语的现有定义的澄清。
这样做的一个很好的理由是让人们从您的应用程序中获取一些代码，将其粘贴到库中，而不是仅仅因为他们使用“您的代码”而强迫他们发布应用程序的代码。
所以恕我直言 - 是的，LGPL 适用于应用程序。
是的，您可以为此目的使用 LGPL。LGPL 中对库的引用并没有真正说明库是什么。例如，有 LGPL 许可的大型应用程序（如 JBoss）。
或者您可以使用例外的 GPL（如 GCC）。LGPL 3 本质上是一个 GPL 3，但有一个例外。
自从您发布原始问题以来，您可以考虑在 2012 年 1 月发布新版本的 MPL：MPL 2.0：不再提及加利福尼亚司法管辖区：http ://www.mozilla.org/MPL/2.0 /。它有点复杂，但也允许用户选择 A/L/GPL 2 和 3 作为替代许可证。
但是，GPL 认为插件是派生作品。
只有当他们重用 GPL 部分的代码时，您才能在 linux 内核中使用适当的插件，例如闭源设备驱动程序。