从个人经验来看，这与我观察到的成功的、有用的开源项目的趋势/增长是一致的，这些项目采用了宽松的BSD类许可证。大约20年前，这样的项目要少得多。作为一名从事客户端/应用软件开发的软件开发者，使用GPL/LGPL许可证非常麻烦，基本上是不可行的，除非我在做个人的小项目，而那时我并不介意要开源其余的代码，或者面临被起诉或被克隆的风险……2010年左右的一个真实例子——我们最终在移动应用代码中包含了LGPL库，并发布了我们对这段代码所做的修改（主要是ARM优化）。当这个应用变得流行后，我们的竞争对手来找我们，要求我们提供应用的源代码——只是因为iOS不支持动态库（所以我们必须静态链接），而给他们对象代码重新链接是不够的（这在LGPL的精神上是满足的），因为他们真的想看看我们是如何绕过iOS相机输入API的……
源讨论从长远来看，GPL代码会变得无关紧要（2015）原帖 176 条评论 · 导入时统计把你的经验，加入这段讨论。
>给他们目标代码以便重新链接是不够的（这符合LGPL的精神） 所以他们可以去见鬼吧？
完整原文> 给他们目标代码以重新链接是不够的（这会满足LGPL的精神） 这不也满足了LGPL v2的字面意思吗？ > 随着程序一起提供完整的对应可读的机器源代码，对于库 [...] 并且，如果该程序是一个与库链接的可执行文件，提供完整的可读的“使用该库的程序”，作为目标代码和/或源代码，以便用户可以修改该库并重新链接以生成包含修改后的库的修改后的可执行文件
完整原文> 只是因为iOS不支持动态库（所以我们必须静态链接） 如果你为封闭的生态系统开发封闭软件，那么依赖GPL仍然是可能的，但这是一个相当矛盾的哲学。我想替代方案可能是从头开始开发所有这些，或者从其他地方获取，很可能会付费，这会使这些成本更加难以承受... 但另一方面我真的不理解这些高昂的成本，因为提供目标代码就足够了。那是什么成本？律师吗？
完整原文是的，你是在说BSD代码，你可以免费获得并且不需要给予任何东西，对你创建封闭源代码的商业程序来说是最方便的。当然。 对于商业库的创建者，比如QT，GPL可能非常方便，因为他们的商业客户不能只是免费获取他们的东西并使用它，而是可以使用GPL进行试用，然后在他们打算这样使用时寻求商业许可。 也就是说，目前使用的每一种许可证对供应商来说都有特定的用途，因此只要我们有不同目标的供应商，这些许可证都不太可能消失。
完整原文> 使用GPL/LGPL是非常麻烦的，基本上是成本高昂的 如果你能遵守许可证的话，其实不是。 如果你想利用静态链接二进制文件中的免费（L）GPL代码，而不需要向你的客户提供源代码，那么这确实是个问题。不过对于LGPL来说，可链接的二进制文件可能就足够了。
完整原文我同意，如果将"成功"定义为"拥有尽可能多的用户"，那么宽松许可的项目更有可能成功。当然，这种"成功"经常导致无偿的志愿者维护者被大公司的员工提交的大量错误报告和功能请求淹没，所以这种方法也有缺点。
完整原文我认为LGPL现在变得尤其不相关。我想在macOS应用中使用GEOS（LGPL 2.1），但正如你指出的那样，风险很高。我认为从长远来看，用Swift重新构建GEOS会显著降低风险。许可的复杂性和不明确性是一个真正的负担。 我认为这不符合LGPL的初衷——只是代码签名阻止了LGPL所设想的动态链接库的使用方式。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。