是否有修改后的LGPL许可证允许静态链接？

LGPL要求，如果程序使用LGPL版本的库，则用户必须能够将程序与库的其他版本重新链接：

...

d）执行以下一项操作：

0）根据本许可条款和相应的应用程序代码，以适合用户并在允许用户重新组合或重新链接应用程序与链接版本的修改版本的方式下传达最小应用程序源，以产生按照GNU GPL第6节指定的方式传送相应的源代码，修改组合工作。

1）使用合适的共享库机制与库链接。一种合适的机制是（a）在运行时使用用户计算机系统上已经存在的库的副本，并且（b）在与链接版本接口兼容的库的修改版本下正常运行。

...

但是，在某些情况下，这可能会带来很大的困难。特别是，Haskell程序几乎总是静态编译的。而且，编译器会进行跨模块优化，因此不可能取出一部分代码并用另一部分代码代替。因此，很难满足此条件。（请参阅Haskell Wiki上的此链接。）

动态链接将是一个解决方案，但是在许多情况下，这是不可能的。例如：

• 某些平台可能根本没有动态链接。
• 某些语言无法进行动态链接。或者，不可能使模块成为多平台。
• 在某些情况下，动态链接会阻止重要的优化。虽然我说这很少是一个严重的问题，但是在像Haskell这样的语言中，性能损失可能是相当大的。

因此，我正在寻找一种标准的类似LGPL的许可证，该许可证不需要重新链接（并且我知道这样做会给用户带来一些自由）。一些项目使用他们自己的LGPL修改，例如wxWidgets。但是，我宁愿使用一些更正式的标准许可证，也许已由某些法律专家检查过，并且与（L）GPL兼容。有这样的东西吗？

（我也想知道这种LGPL修改是否会带来一些不可预见的后果。）

我很惊讶没有人提到Mozilla公共许可证。它与LGPL相似，只不过它允许静态链接。MPL版本2与GPL / LGPL兼容。

Mozilla公共许可证（MPL 2.0）与较小的GNU通用公共许可证（LGPL 3.0）

wxwidgets基本上是通过LGPL +静态链接获得许可的

...基本上是L-GPL（图书馆通用公共许可证），但有例外规定，二进制形式的衍生作品可以按用户自己的方式分配。该解决方案可以满足那些希望使用wxWidgets生产GPL软件的人，以及那些生产专有软件的人。

wxWidgets是导致此决定的讨论中的经过认证的开源软件参与者，其中包括来自Abisource，Robert Roebling，Julian Smart，Markus Fleck，Karsten Ballueder的人员，以及Richard Stallman的一些建议。Richard已确认新许可证与GPL的应用程序兼容。但是，对专有应用程序没有明显的限制。

wxWindows的许可已批准开放源码促进会，你可以找到他们的网站上牌照这里 ...

IANAL，但让我相信，一种解决方案是为非LGPL零件提供目标文件。这样，用户可以重新链接程序，因此可以自由更改LGPL部分，从而满足LGPL的要求。

换句话说，您需要具有源包，其中包含LGPL源和非LGPL代码的已编译目标文件。显然，您随后需要为发布二进制文件的每种不同体系结构提供目标文件，但是我认为这不是什么大问题。

从开发的角度来看，最简单的方法可能是在构建用于分发的二进制文件时，仅使构建系统同时构建源程序包。

我在Google上找到了一个：OpenScales许可证

OpenScales是根据GNU较小公共许可证（LGPL，可在此处）的版本3发行的，其示例与静态链接异常有关（请参见下文）。

除LGPL许可文本外，LGPL条件的例外适用于OpenScales：

作为GNU通用通用公共许可证版本3的特殊例外，您可以将组合工作中的可执行文件传送给第三方，该可执行文件以静态或动态方式链接可执行文件中该库的部分内容，从而传达了最小对应源，但只要您使用的是未经修改的公共发行版本的库，就无需根据GNU通用通用公共许可第4d0节传达相应的应用代码。此异常不会使可执行文件可能受GNU通用公共通用许可证或GNU通用公共许可证覆盖的任何其他原因无效。

虽然这不是标准的，但我不知道是否存在。

您将如何继续保证用户自由？我相信“正确”的答案是静态链接动态加载库的填充程序。