tags:

views:

98

answers:

2

I am using an LGPL library in my code. For my needs, I need to modify the code in the library.

How do I mark the jar file that it contains modified code? Some txt file in the jar? In that case, what do I write in the txt file?

I will include in the license agreement that we are distributing a modified version of the jar, but my question is about marking the jar itself.

+1  A: 

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.

extraneon
+2  A: 

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:

  1. Conveying Modified Versions.

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.

The long answer: LGPL Version 2.1

From version 2.1 of the LGPL itself:

  1. 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.

Clinton
In LGPL, http://www.gnu.org/licenses/lgpl-2.1.html, I found the line "b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change."and "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."which suggest that I should mark the file and state something in my license agreement. At least according to my legal guy.
David Göransson
@David, sorry the snippet I provided was from version 3.0 of the LGPL. Since here you reference 2.1, I will assume the library you are modifying is actually 2.1: 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... You can pretty much achieve similar goals by sending in a patch to the creators of library 'bar'.
Clinton
@David - I.e. The prominent notices are also usually performed at the beginning of your modified source files in the LGPL license comment block.
Clinton