If you have fixed a bug, or added a feature why not submit it back to the original authors by way of a patch? If they accept it, the next version of the library will include your fixes and you won't need to worry about shipping a modified library! Sharing your changes/improvements to the library is the essence of the license, temporarily using a slightly modified version of the library while you are waiting for your submitted improvements is fairly common practice (see stuff about vendor branches). Becoming part of the development community means you are no longer shipping a 'modified' version of the library, but actively contributing your improvements to the original library for the common good.
If you modify a copy of the Library, and, in your modifications, a facility refers to a function or data to be supplied by an Application that uses the facility (other than as an argument passed when the facility is invoked), then you may convey a copy of the modified version:
a) under this License, provided that you make a good faith effort to ensure that, in the event an Application does not supply the function or data, the facility still operates, and performs whatever part of its purpose remains meaningful, or
b) under the GNU GPL, with none of the additional permissions of this License applicable to that copy.
As long as you comply with the rest of the license text, you don't necessarily need to 'mark' the jar itself, with a text file or otherwise. For compilation reasons, you could follow the suggestion of extraneon and use a slightly different jar name. You could use a vendor branch or something to maintain the differences between your modifications and the original library. Here you are 'forking' the project, creating your own derivative work - the essence here is to share your changes and improvements to the source with the world.
You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
a) The modified work must itself be a software library.
b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change.
c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License.
d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful.
(For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.)
In essence you must say: Hey here is library 'foo', a modified version of library 'bar', here you can use my version of library 'foo' - it too is available under LGPL2.1. The prominent notices are also usually performed at the beginning of your modified source files in the LGPL license comment block. Again your are forking the library.
给罐子起一个不同的名字。里面的类将具有相同的名称，因此依赖于它的代码不会有找到它的问题（如果新的 jar 位于类路径上）。
当然，通过在清单文件中添加一些信息来记录您的更改总是明智的，也许还可以在 jar 本身中添加一个更改日志文件。
Give the jar a different name. The classes inside will have the same names, so code depending on it won't have a problem finding it (if the new jar is on the classpath).
It's of course always wise to document your changes by adding some info in the manifest file, and perhaps also a changelog file in the jar itself.
发布评论
评论（2）
简短的回答：避免问题
如果您修复了错误或添加了功能，为什么不通过补丁的方式将其提交回原始作者呢？如果他们接受，该库的下一个版本将包含您的修复，您无需担心发布修改后的库！共享对库的更改/改进是许可证的本质，在等待提交的改进时暂时使用库的稍微修改的版本是相当常见的做法（请参阅有关供应商分支的内容）。成为开发社区的一部分意味着您不再发布库的“修改”版本，而是为了共同利益积极贡献对原始库的改进。
长答案：LGPL 3.0 版
来自 LGPL 本身的 3.0 版< /a>:
只要您遵守许可证文本的其余部分，您不一定需要使用文本文件或其他方式“标记”jar 本身。出于编译原因，您可以遵循 extraneon 的建议并使用略有不同的 jar 名称。您可以使用供应商分支或其他东西来维护您的分支之间的差异修改和原始库。在这里，您可以“分叉”该项目，创建您自己的衍生作品 -这里的本质是与世界分享你对源代码的改变和改进。
长答案：LGPL 版本 2.1
来自 LGPL 版本 2.1本身：
本质上你必须说：嘿，这里是库“foo”，库“bar”的修改版本，在这里你可以使用我的库“foo”版本' - 它也可以在 LGPL2.1 下使用。突出的通知通常也出现在 LGPL 许可证注释块中修改后的源文件的开头。你再次分叉了图书馆。
The short answer: Avoid the issue
If you have fixed a bug, or added a feature why not submit it back to the original authors by way of a patch? If they accept it, the next version of the library will include your fixes and you won't need to worry about shipping a modified library! Sharing your changes/improvements to the library is the essence of the license, temporarily using a slightly modified version of the library while you are waiting for your submitted improvements is fairly common practice (see stuff about vendor branches). Becoming part of the development community means you are no longer shipping a 'modified' version of the library, but actively contributing your improvements to the original library for the common good.
The long answer: LGPL Version 3.0
From version 3.0 of the LGPL itself:
As long as you comply with the rest of the license text, you don't necessarily need to 'mark' the jar itself, with a text file or otherwise. For compilation reasons, you could follow the suggestion of extraneon and use a slightly different jar name. You could use a vendor branch or something to maintain the differences between your modifications and the original library. Here you are 'forking' the project, creating your own derivative work - the essence here is to share your changes and improvements to the source with the world.
The long answer: LGPL Version 2.1
From version 2.1 of the LGPL itself:
In essence you must say: Hey here is library 'foo', a modified version of library 'bar', here you can use my version of library 'foo' - it too is available under LGPL2.1. The prominent notices are also usually performed at the beginning of your modified source files in the LGPL license comment block. Again your are forking the library.
给罐子起一个不同的名字。里面的类将具有相同的名称，因此依赖于它的代码不会有找到它的问题（如果新的 jar 位于类路径上）。
当然，通过在清单文件中添加一些信息来记录您的更改总是明智的，也许还可以在 jar 本身中添加一个更改日志文件。
Give the jar a different name. The classes inside will have the same names, so code depending on it won't have a problem finding it (if the new jar is on the classpath).
It's of course always wise to document your changes by adding some info in the manifest file, and perhaps also a changelog file in the jar itself.