在付费Android应用程序中使用LGPL库

如果您正在制作付费的Android应用程序，您可能会遇到特定问题LGPL的问题：可替代性。通常，它指出当您分发组合作品时，您必须为用户提供用不同版本（例如，更新版本）替换库的可能性。如前所述，DEX文件非常值得怀疑。 单个DEX文件的替代方法是从依赖库中创建一个在LGPL上发布的单独应用程序。在这样的应用程序中，您可以创建从付费应用程序连接到的服务。然后，用更新的版本替换LGPL库只重新编译并重新安装库的APK是必需的。 当然，麻烦是现在你要安装多个APK。     

在Android免费或付费应用程序中使用LGPL是合法的，但要符合LGPL，您必须： 向用户显示所使用的库以及在何处查找原始代码; 配置proguard以不混淆LGPL涵盖的代码; 避免在您的应用中检查签名合规性; 向用户提供如何更换库的指示。 对于第4点，您可以指示使用dex2jar，替换LGPL代码并重新签名APK。它需要为用户做很多工作，但有可能做到这一点，并允许最终用户重新组合或重新链接代码，正如LGPL所说。此外，如果您的应用使用任何Google服务，则用户需要创建帐户以生成自己的API密钥等。     

我不是律师，但根据我对GNU宽通用公共许可证3.0的理解，第4节明确规定了静态链接，因为要求规定：   如果您还执行以下各项操作，您可以根据您选择的条款传达合并作品，这些术语合在一起，实际上不会限制对合并作品中包含的库部分的修改以及用于调试此类修改的逆向工程。         [...]   d）执行以下操作之一：         0）根据本许可条款和相应的应用程序代码，以允许用户重新组合或重新链接应用程序与链接版本的修改版本的条款相应的形式传送相应的应用程序代码，以生成修改的组合工作，按照GNU GPL第6节规定的方式传送相应的来源。   1）使用合适的共享库机制链接库。合适的机制是（a）在运行时使用已经存在于用户计算机系统上的库的副本，以及（b）将与与链接版本接口兼容的库的修改版本正确地操作。       （强调我的。） Android APK的性质无法实现第4d.0节：APK被编译为Dex并作为整体签名，包含引用的库，因此如果没有原始源代码，密钥库和密钥库密码，则无法完成交换库。 可以通过部署两个APK来实现第4d.1节： 一个APK包含LGPL库，反过来开源并在LGPL下获得许可 另一个专有APK引用LGPL应用程序。 但是，如果没有明确添加用户继续下载LGPL依赖关系的要求，则无法直接通过Google Play部署此类应用程序，这需要在Google Play上作为单独的应用程序进行部署。这对最终用户来说非常繁琐，并且实际上不是典型消费者应用程序的选项。 根据在William Tate的回答中与Falken教授的讨论，LGPL的条款可能更适用于通过本机代码包含的C库，因为它们作为单独的库驻留在APK中。虽然APK无法签名，但可以在替换目标文件的情况下重新打包APK。从我的角度来看，这在技术上符合许可证的要求。     

droidText库（用于在Android上导出为PDF格式并在LGPL下发布）详细解释了如何使用它们的库并仍然符合LGPL： http://code.google.com/p/droidtext/wiki/LGPLCompliance 我发现它非常有帮助。基本上你使用utililty（dex2jar）来获取dex文件的库的jar - 从而允许和最终用户在需要时使用更高版本的droidText库进行更新。     

我一直认为LGPL非常“灰色地带”。尽管应该如何使用LGPL代码/库等具体细节，但它并不一定反映作者的确切要求。 我个人建议联系作者，解释您的疑虑，并询问他们是否乐意让您使用它。     

这应该概述您的主要问题：http：//answers.google.com/answers/threadview/id/439136.html 其中大部分似乎都在披露您对图书馆的使用，并确保您遵守许可证的分发规则。