我想在基于Web的源代码托管服务上发布用基于类，面向对象的编程语言（Java）编写的软件库，该软件库允许将项目的分支合并到主项目（通过pull 合并到 GitHub中）要求）。我已经在网络上进行了研究，并对如何许可该软件给予了很多思考。在以下假设中（从IANAL角度来看）我是否正确？

• LGPL和MPL都促进共享对在其他软件项目中使用的LGPL / MPL许可软件的修改。我可以不要求修改后的库的用户托管库的单独分支，而可以促进对原始库的贡献（例如，通过拉取请求）。

• 主要区别在于必须如何将MPL / LGPL许可代码链接到项目中。MPL源代码文件可以直接复制到（可能是）专有软件项目（静态链接）中，而LGPL许可代码必须动态链接（宽松地链接到可能是专有软件项目的链接），以便最终用户可以切换出许可软件许可软件库的另一个版本的库）。

• 动态链接（因此LGPL）在打包专有软件产品时增加了额外的障碍，而不是通过静态链接（以及MPL）来促进对开源软件库的更多贡献。有一个修改LGPL允许静态链接。

• 还有没有其他相关的差异（从IANAL角度）。

• 在旧的许可证版本不适合我的需要不如最新的。

如您所见，我的主要要求是对软件库的修改（可能对公众有用）保持开放源代码，而不会限制在专有产品中使用软件库。
没有许可证还要求将与原始作品相关的软件库扩展作为开源发布，因为相关术语的范围可以很小/很大，因此最终不能作为GPL用于专有产品（不发布全部源代码）。

我很想使用修改后的LPGL，但是另一方面，它不受欢迎。基于以上几点，我更喜欢MPL。
问题：我的上述说法正确吗？考虑到我的要求，我应该选择哪个许可证？

解决方案：在受欢迎的讨论中，我选择坚持使用MPL是因为它受欢迎，链接自由并且它是未经修改的正式许可。

我相信您已经准确说明了Mozilla公共许可证和GNU通用公共许可证之间的区别，并且两者都可以满足您的需求，但是您跳过了两个许可证之间最重要的区别：

谁可以制作新版本？

MPL（第10节）和LGPL（第14节）在其许可中均包含将当前版本替换为后一版本的权利，并且对这些许可中的内容没有实际限制。尽管Mozilla基金会或Free Software Foundation极不可能做出某种疯狂的举动，例如制定一条条款，说“对该软件的所有贡献都归我们所有”，但这并不是不可能的范围。组织将发布您不喜欢的新许可证版本。

这提出了关于使用“修改的LGPL”的另一点。

修改后的许可证不是同一份许可证！

尽管您具有惊人的能力来指定自己的许可条款，并且本质上可以说“您可以按照GPL进行分发，但是您需要将我的名字记入您的信用额中，并向我支付所产生收入的1％”，只要您这样做，便会根据他人的工作创建新的许可证。这意味着您没有使用MPL或LGPL，而是使用了新的“ mucaho许可证”。

这意味着，如果您需要在法庭上捍卫对许可证的解释，您可能不会从原始许可证的作者那里得到任何帮助，而且他们很有可能提起诉讼，说应使用THEIR版本并不是你的。

当然，这两个都是次要点。除非您希望将代码直接合并到大型项目中，否则即使“许可证普及”也无关紧要。

就个人而言，如果您喜欢专有的兼容性，或者在实际的MPL和必须基于LGPL手动编辑的其他许可证之间进行选择，我认为MPL是更好的选择。除非您有理由不使用MPL，否则请选择基金会支持的产品，而不是可能在没有任何帮助的情况下将您留在法庭上的产品。

DougM和AER的答案很合理。带有静态异常的MPLv2和LGPLv3对于将触发copyleft的事件相同。但是，我认为LGPL和MPL之间缺少另一个非常重要的区别。触发copyleft时，copyleft适用于：

• 对于MPL：与原始库完全相同的文件
• 对于LGPL：针对“基于库的作品”，而不是“使用库的作品”。因此LGPL可以将他的copyleft扩展到新文件。

边缘案例：使用MPL可使用户不共享他们的改进

MPL是文件级的copyleft许可证。这意味着，如果有人（静态地或动态地）将其嵌入到更大的项目中并对文件进行更改，那么他只需要释放对该特定文件所做的更改。

如果您担心保持代码库的完整性开放，那么在某些极端情况下，MPL的这种Copyleft效果可能不足。

例如，某人可以获取项目的主文件之一，添加“ import my_private_new_file”，然后通过添加“ my_private_new_file.newAwesomeFeature.run（）”来修改您的主方法。

这样，他可以向您的项目添加新功能，同时仅释放修改后的主文件，并在“ my_private_new_file”中将新功能的实际逻辑保持为封闭源。

将主文件返回给社区只是向您提供了“嘿，您添加了一个新功能”的信息，但是它不能使您将这个新功能公开纳入……如果新功能紧密相关，可能会很烦人。 -与您的图书馆正在尝试解决的问题有关。

显然，这是一个极端情况，很少有人愿意这样做，但这是在使用MPLv2时必须意识到的风险。

LGPL的编写禁止此类行为。看到：

• https://www.javalobby.org//java/forums/t15903.html#91819035
• LGPL允许我这样做吗？

我引用了原始LGPL许可证：

请密切注意“基于库的作品”和“使用库的作品”之间的区别。前者包含从库派生的代码，而后者必须与库结合才能运行。

Copyleft仅适用于“基于库的作品”。现在在实践中什么是“基于库的作品”？它留下了解释的空间。这不仅是一件好事，因为它意味着遵守您的许可证变得更加复杂，因此令人恐惧。它可能导致某些人根本不使用您的库。

从这个意义上讲，LGPL比MPL更具限制性，而且对项目的完整性也更具保护作用。

MPL使来自专有领域的用户可以更轻松地修复和使用您的库，同时仍然必须共享此修复程序

MPL的一个优点是，如果用户在您的库中发现错误，则可以直接在文件中修复该错误，而不必放弃所有代码，而只需提供修复程序即可。实际上，将工作分配给客户时，他可以提供指向包含修复程序的项目分支的链接，他是个好人。

通过使用LGPL，事情变得更加复杂。如果有人分叉您的项目，修复错误并将其静态嵌入到他的专有软件中，则他必须向用户分发LGPL下的“基于库的工作”。这是一个相当晦涩的概念，尤其是当库是静态嵌入的...就此而言，我认为这是原始LGPL中不存在“静态”异常之类的原始原因。它使“基于库的工作”的标识变得很简单：这是您在专有软件中调用的动态库。

结果，与LGPL相比，MPL使专有供应商更容易使用专有的软件并将其发送到库。

同时，大多数时候专有供应商没有资源也没有时间去研究您复杂的库，因此很可能不会自行修复。他们宁愿在您的GitHub仓库上打开一个问题，或者在邮件列表中发送电子邮件并等待您的修复。

在这方面，LGPL实施了更多此类行为。但是真的需要执行吗？

结论

在LGPL和MPL之间进行选择是一个棘手的问题，并且与软件许可一样，这取决于您的目标。这两个许可证非常相似，但同时却截然不同。它们是为非常不同的目标和理念而设计的。

LGPL由自由软件基金会创建，旨在使自由软件库在专有世界中得到广泛使用，但始终牢记促进自由软件并与专有软件作斗争的想法。这都是他们意识形态战略的一部分。请参阅：https： //www.gnu.org/licenses/why-not-lgpl.html

MPL是由Mozilla设计的一种实用许可证，用于对原始库进行某种形式的共享，同时仍鼓励人们在顶部制作专有软件和附加组件（包括Mozilla本身），而这是FSF授权的做法LGPL，但仍认为有害。

从本质上讲，MPLv2被许多人视为许可许可证，而LGPLv3（包括静态异常）很少被称为这种方式。

编辑

我忘了提到一些重要的事情。LGPLv3（有或没有静态异常）均禁止透视。您可能会认为这是一个“细节”，但实际上并非如此，这取决于您的目标。您是否关心用户自由？然后，这不是一个细节。您是否在乎可以在Apple的设备上使用图书馆？VLC更关心被使用，因此他们决定使用不包含此类限制的LGPLv2。同样，这也是Linux继续使用GPLv2的原因之一。MPLv2也没有任何限制，因为它是在考虑更“实用”的开源哲学而不是FSF意识形态的情况下创建的许可证。

我可能还错过了其他类似的“次要”事情。