我在我的代码中使用了 LGPL 库。为了我的需要,我需要修改库中的代码。
如何标记包含修改代码的 jar 文件?jar中的一些txt文件?在那种情况下,我在txt文件中写了什么?
我将在许可协议中包含我们正在分发 jar 的修改版本,但我的问题是关于标记 jar 本身。
简短的回答:避免这个问题
如果您已修复错误或添加了功能,为什么不通过补丁将其提交给原作者呢?如果他们接受它,该库的下一个版本将包含您的修复,您无需担心运送修改后的库!将您的更改/改进共享到库是许可证的本质,在等待提交的改进时暂时使用库的稍微修改版本是相当普遍的做法(请参阅有关供应商分支的内容)。成为开发社区的一员意味着您不再发布库的“修改”版本,而是为共同利益积极贡献您对原始库的改进。
长答案:LGPL 3.0 版
从LGPL 本身的 3.0 版开始:
- 传送修改后的版本。
如果您修改库的副本,并且在您的修改中,设施是指由使用该设施的应用程序提供的函数或数据(除了作为调用设施时传递的参数),那么您可以传达修改版本的副本:
- a) 根据本许可,前提是您真诚地努力确保在应用程序不提供功能或数据的情况下,该设施仍然运行,并执行其目的的任何部分仍然有意义,或
- b) 在 GNU GPL 下,本许可证的任何附加许可均不适用于该副本。
只要您遵守许可文本的其余部分,您不一定需要使用文本文件或其他方式“标记”罐子本身。出于编译的原因,您可以遵循 extraneon 的建议并使用稍微不同的 jar 名称。您可以使用供应商分支或其他东西来维护您的修改与原始库之间的差异。在这里,您正在“分叉”项目,创建自己的衍生作品 - 这里的本质是与世界分享您对源代码的更改和改进。
长答案:LGPL 2.1 版
从LGPL 本身的 2.1 版开始:
您可以修改您的图书馆或其中任何部分的一个或多个副本,从而形成基于图书馆的作品,并根据上述第 1 条的条款复制和分发此类修改或作品,前提是您也满足所有这些条件:
- a) 修改后的作品本身必须是软件库。
- b) 您必须使修改的文件带有显着的通知,说明您更改了文件和任何更改的日期。
- c) 您必须根据本许可条款将全部作品免费许可给所有第三方。
- d) 如果修改后的库中的设施指的是由使用该设施的应用程序提供的函数或数据表,而不是作为调用该设施时传递的参数,那么您必须做出善意的努力以确保在应用程序不提供此类功能或表格的情况下,该工具仍然运行,并执行其目的的任何部分仍然有意义。(例如,库中计算平方根的函数具有完全明确定义的独立于应用程序的目的。因此,第 2d 小节要求该函数使用的任何应用程序提供的函数或表必须是可选的:如果应用程序不提供它,平方根函数必须仍然计算平方根。)
本质上你必须说:嘿这里是库'foo',库'bar'的修改版本,在这里你可以使用我的库'foo'版本-它也可以在LGPL2.1下使用。突出的通知通常也出现在 LGPL 许可证注释块中修改的源文件的开头。你又在分叉图书馆。
给罐子起一个不同的名字。里面的类将具有相同的名称,因此依赖于它的代码将不会有问题找到它(如果新 jar 在类路径上)。
当然,通过在清单文件中添加一些信息来记录您的更改总是明智的,也可能在 jar 本身中添加一个更改日志文件。