用Java重新打包库JAR

bgr*_*nks 4 java licensing packaging jar

我一直在将第三方库JAR提取到我的开源Java库中,以便依赖项在运行时工作.

我记得当我在Eclipse中尝试这样做的时候(不同的项目)它产生了警告,在执行此操作之前检查许可.

关于何时可以将库内容重新打包到JAR中,应该如何完成以及哪些广泛使用的许可证禁止它的一般规则究竟是什么?

具体来说,我重新打包的库使用BSD和LGPL.

在此先感谢您的帮助.

编辑

我实际上最终分离出依赖项以防止代码冲突,正如几位评论者所建议的那样.再次感谢您提供的建议和信息.

Nic*_*udo 6

我个人所做的是确保我使用的库都没有明确禁止重新分发.如果他们这样做,那你就不走运了.既不是BSD也不是LGPL,所以你应该没问题.我想不出一个理智的开源许可证.

一旦您满意,您不会通过重新包装和分发许可证来违反许可条款,您需要确保在其他方面尊重它们.我发现以下步骤足以满足99.99%的开源许可证:

  • license.txt在你的JAR文件的根目录下创建一个文件(有些人把它放进去META-INF,但我知道没有规则或约定,并认为这只是一个偏好问题).
  • 列出您导入的所有外部库以及分发它们的许可证license.txt.
  • 写下适用的所有许可证的完整文本license.txt.
  • 理想情况下,链接到每个图书馆的网站,下载页面和许可页面(如果有).

这应该确保您不会违反任何主流许可证,除了GPL.我不是律师,也不是GPL的专家,我给你的关于如何尊重它的任何建议可能最终都是完全错误的,所以我宁愿不要误入歧途.

还有一些你可以做的事情,但更多的是礼貌的问题:

  • 如果您正在编写面向应用程序的用户(webservice,UI应用程序...),请链接到您在该About部分中使用的库.
  • 让图书馆的维护者知道你正在使用和打包它 - 一些作者喜欢使用他们的工具维护一份流行的软件列表.

虽然这可能听起来像很多工作,但它的工作远远少于编写和维护实际库.

编辑:我刚刚意识到你正在开发一个,而不是一个应用程序.在这种情况下,我的答案实际上并不适用:将您的依赖项打包到库的JAR中是非常糟糕的形式.如果有的话,它会让第三方开发人员更难将您的库与现有的构建工具和依赖管理系统(maven,ant/ivy ......)集成.

如果您想简单易懂,只需将所有依赖项的JAR包含在/lib分发文件的文件夹中即可.

再次重申我的观点:我相信你会被打包的依赖关系疏远多数开发商磁带库的JAR文件,而不是它.如果没有解决问题,我当然会提交错误报告并寻找备选方案.