There may be an LGPL clause that would answer my question directly but I didn't find anything obvious so I need help in understanding this. I want to create a custom C3P0 connection provider that will allow me to access the underlying C3P0 datasource and execute administrative commands on it, including forcefully closing it. Since hibernate's ConnectionProvider interface itself can't be used to make this possible, I can't make this as a generic solution, but a crude custom class that can be used only with our system, which is a commercial product (not a library).

My question is, if using the existing C3P0ConnectionProvider code to start this custom class and adding all the additional logic that I need (kind of like coping the class and modifying it) will obligate me to any specific LGPL clauses? At the simplest, this is like looking at the JDK source for example usage (e.g., to create a custom TextField), but strictly speaking this could be considered modifying the hibernate source code. Can anyone help me understand what is involved here?
- Do I need to make sure the code is available for others?
- Do I have to bundle the modified class separately (and avoid linking with the rest of my system) to avoid clause with being able to "reverse engineering"?

I could have circumvent the licensing by extending the C3P0ConnectionProvider and adding more functions, but the underlying datasource is declared private, so I can't access it, so this will not work. Will it probably easier (from license point of view), to modify the existing class following LGPL guidelines and first make the datasource protected, and then be free to create a custom class that extends this class?

I would appreciate any inputs.

Thank you,
Irha

So, I'm not a lawyer, but I don't think LGPL prevents you from doing anything you want for your own internal use. If you're distributing the software, I think there's a definitional issue of whether your new ConnectionProvider is a modification of hibernate libraries or merely a use of them, and if the latter, LGPL doesn't require you to publish. But this is all stuff I don't really know that much about.

I do know a good bit about c3p0, though. Though writing your own ConnectionProvider is easy to do (hibernate was very sensibly written that way), you may not have to bother. Recent c3p0s offer an alternative means of finding all c3p0 DataSources active within a virtual machine. If what you want to do is have programmatic access to your c3p0 DataSource, download the most recent c3p0-0.9.1 prerelease, and check out the documentation and API docs for the C3P0Registry class.

Good luck!
Steve

The LGPL license is for the libraries, but is there a different license for using the source? My use case is very trivial and has alternatives as you suggested below, but I want to understand this out of curiousity on what are the terms govering the use parts of the source code.


This information is helpful, and could provide me with most of what I need. Their website has been inaccessible through the day, so I will check it later. Thank you.

I believe the standard interpretation would be:

You can create your own implementation of ConnectionProvider and this would just count as usage of Hibernate so you can licence it however you like.

BUT

If you base you connection provider on an existing one by copying and modifying source code, then it would count as a derivative work and you'd need to license your connection provider implementation (not your whole application) under lGPL.

As swaldman said, you only need to worry if you distribute it, the GPL and lGPL only guarantee that anyone who has access to lGPL and GPL licensed binaries can obtain the source code if they so desire.

So if you put a note saying something to the effect of com.randomcompany.project.ConnectionProvider is licensed under lGPL, contact random company to obtain the source you'd be fine.


Disclaimer
I'm not a lawyer, this is just my understanding of the lGPL. If you want to be really sure you'd need to check it with a lawyer.