Java 如何标记lgpl库已修改

我在代码中使用了LGPL库。为了满足我的需要，我需要修改库中的代码

如何标记包含修改代码的jar文件？jar中有txt文件吗？在这种情况下，我应该在txt文件中写什么

---

我将在许可协议中说明，我们正在分发jar的一个修改版本，但我的问题是如何标记jar本身。

给jar一个不同的名称。内部的类将具有相同的名称，因此依赖于它的代码在查找它时不会有问题（如果新jar位于类路径上）

---

当然，明智的做法是在清单文件中添加一些信息，或者在jar本身中添加一个变更日志文件来记录您的更改。

简短的回答是：避免问题。

如果您已经修复了一个bug，或者添加了一个特性，为什么不通过补丁将其提交给原始作者呢？如果他们接受，库的下一个版本将包含您的修复，您就不必担心发布修改过的库了！共享对库的更改/改进是许可证的本质，在等待提交的改进时临时使用库的稍加修改的版本是相当常见的做法（请参阅有关供应商分支的资料）。成为开发社区的一部分意味着您不再提供“修改”版本的库，而是为了公共利益积极地对原始库进行改进

详细答案：LGPL 3.0版

从的3.0版：

传达修改过的版本

如果您修改了库的副本，并且在您的修改中，设施引用了由使用该设施的应用程序提供的函数或数据（不是作为调用该设施时传递的参数），则您可以传递修改版本的副本：

• a） 根据本许可证，前提是您真诚地努力确保，在应用程序不提供功能或数据的情况下，设施仍在运行，并执行其目的的任何部分，或
• b） 根据GNU GPL，本许可证的任何附加权限均不适用于该副本

只要您遵守许可证文本的其余部分，就不必用文本文件或其他方式“标记”jar本身。出于编译的原因，您可以按照extraneon的建议使用稍微不同的jar名称。您可以使用一个或一些东西来保持修改与原始库之间的差异。你就是这个项目，创造你自己的衍生作品——这里的本质是与全世界分享你对源代码的更改和改进

详细答案：LGPL版本2.1

从的2.1版：

您可以修改图书馆或其任何部分的一份或多份副本，从而形成基于图书馆的作品，并根据上述第1节的条款复制和分发此类修改或作品，前提是您还满足以下所有条件：

• a） 修改后的作品本身必须是一个软件库
• b） 您必须使修改后的文件带有明显的通知，说明您更改了文件以及任何更改的日期
• c） 您必须根据本许可证的条款，将整个作品免费许可给所有第三方
• d） 如果修改库中的某个设施引用了使用该设施的应用程序提供的函数或数据表，而不是作为调用该设施时传递的参数，则您必须真诚地努力确保在应用程序不提供该函数或数据表的情况下，该设施仍在运行，并执行其目的中任何有意义的部分。 （例如，库中用于计算平方根的函数有一个完全独立于应用程序的明确定义的用途。因此，第2d小节要求该函数使用的任何应用程序提供的函数或表必须是可选的：如果应用程序不提供平方根，则平方根函数仍必须计算平方根。）根。）

---

本质上你必须说：嘿，这里是库'foo'，一个库'bar'的修改版本，在这里你可以使用我的库'foo'版本-它也可以在LGPL2.1下获得。突出的通知通常也在LGPL许可证注释块中修改的源文件的开头执行。你又在用叉子叉图书馆了

在LGPL中，我发现行“b）您必须使修改的文件带有明显的通知，说明您更改了文件和任何更改的日期。”和“c）您必须使整个作品根据本许可条款免费许可给所有第三方。”这建议我应该标记文件并在许可协议中声明一些内容。至少根据我的律师的说法。@David，对不起，我提供的代码片段来自LGPL的3.0版。由于这里您引用了2.1，我将假设您正在修改的库实际上是2.1：本质上，您必须说：嘿，这里是库'foo'，库'bar'的修改版本，这里您可以使用我的库'foo'版本-它也可以在LGPL2.1下获得。。。通过向库“bar”的创建者发送补丁，您几乎可以实现类似的目标。@David-即，突出的通知通常也会在LGPL许可证评论块中修改源文件的开头执行。我投票将此问题作为离题问题结束，因为它涉及许可或法律问题，不是编程或软件开发。有关详细信息，请参阅。