I couldn't find any info in the forums about this, so I thought I'd just ask. Are there any license issues with obfuscating hibernate.jar in order to reduce the bytecode size? As you know, the jar size can be dramatically reduced when such a technique is applied. This is for unmodified Hibernate sources. Yes, I understand that changes to the sources would be covered under LGPL, but I am not sure if the renaming of the classes with the goal of reducing jar size is the same.

Please, this is not an attempt to start a flame war! If the Hibernate team views obfuscation of unchanged sources/binaries contrary to the license, then that is fine and just means that Hibernate any any of its required dependencies ( even non-LGPL ) must not be obfuscated. I just want clarification.

Thanks.

This is plain LGPL. If you distribute a binary built from modified source, you must distribute the source so that the receiver can exercise the same rights.

Thanks for the quick reply. I do understand that modified sources must be distributed to provide the receiver with the same rights. However, what if the sources were unmodified? In other words, the class files are run through an obfuscator which abbreviates the binary class file names and doesn't touch the source. It's sort of a packaging issue where the binaries are touched. However, I understand providing the users with the same rights is required, so I'm wondering if providing the users with the mapping of class names to their abbreviated names would be sufficient ( or even a script to perform this ). The goal is not to change any Hibernate functionality, just to compress the jar.

I suppose it would be a clearer case if the sources were modified ( e.g. package/class names renamed ) and provide the entire modified sources to the users as well as the binary built on it. This seems like it would be following the letter and spirit of the LGPL. The users would be able to make changes and re-compile the modified sources at will while the goal of reducing the jar size would be also achieved.

Thanks.

I think in your case it is sufficient to distribute instructions how to recreate the exact same binary from unmodified Hibernate source, e.g. a script.

Great! Thanks for your insight!