PDA

View Full Version : GNU LGPL and other related questions



mtnbiker66
27th June 2012, 01:42
Good evening all --

At the risk of getting my head chopped off by some folks who obviously know more and like to point out how stupid others are, I need to ask a few questions related to licensing and the best method to handling some app problems within those confines...

A friend has contracted with a client to produce an app for them under the GNU LGPL terms, which if I'm understanding things correctly means everything is open source. My friend has a very large application written in C++ which is not user friendly and requires a manually configured file to be fed to it to produce the output, so he asked me a few months ago to write an wrapper app which instead of requiring him to modify the input file for each simulation would let him (and his client) to enter data thru my app (with data stored in a DB), and have my app generate the file that his app needs. Basically, my app needs to interact with his app, leading to my questions.

1) If I call his executable (which I've done successfully) do I need to provide his code in the deliverable?
2) If I convert his app to a library and call it that way (haven't tried this) do I need to provide his code?
3) Does his code need to be included within my app?

I have tried to import his code into mine and have unsuccessfully been able to call his "main"; there is no header file and I've tried to make it work with EXTERNs (I'm am not a C++ expert in the least) but no luck. I have also tried to convert his main to a class and call it that way, but now I'm getting a "symbol(s) not found..." error that I'd rather not try to troubleshoot over 50,000+ lines of code, so I guess the *big* question is, what should be the best approach to dealing with this situation and stay within the GNU LGPL agreement? Call the executable (works), and if so do I have to provide the code behind that? Convert his app to a library (not been tried) and leads to the same questions? Fold his app into mine and try to call his "main" without a header file for it (with my C++ experience limited to this app)? Or fold his app to mine and create a header file for his main and work thru the "symbol not found" error?

To sum it all up -- what's the best way to go about combining two apps and stay within the GNU LGPL agreement?

thanks!!



Kodi

ChrisW67
27th June 2012, 03:18
These are questions for legal counsel in your part of the world. Your friend has a contract. What does your code have to do with his/her contract?

In general, using a library provided under the LGPL (like Qt) is not restricted by the license but copying or distributing such a library is. Use of an LGPL library by your program does not require release of your source code unless that is required to provide the end-user freedom of substituting other versions of the LGPL library (i.e dropping in a later version of Qt libs for example). That is why using LGPL libraries is typically done with dynamic libraries because they can be replaced without relinking your application. If you build code from an LGPL program into your code then you must provide a mechanism to allow those portions to be replaced by an end user: that could be source, or it could be compiled objects and a method to link the final result together.

If you produce modified versions of the LGPL library itself then there are requirements to clearly identify those changes and release them as source (s2).

Bear in mind that works for hire, as much programming is, typically make the client the copyright holder by default unless a contract says otherwise. They get the source you write for them.

mtnbiker66
27th June 2012, 16:02
Great reply, gives me more to think about it :) Basically his contract states that all code be turned over to the client upon completion of the project but I guess that's where it gets a little sticky.

Let me simplify a little bit. My friend has as a massive piece of software (couple of million lines) he's written that he either licenses out to clients or runs for them and gives them the results. Clients that license the software have to spend hours and hours creating a flat file of data which they then feed to the software, but when he runs the software he's created a helper programmer (itself a rather large app) which takes the data in a rawer format and produces the complicated flat file. This is the app I'm referecing in my app. This is actually where I was confused a little with the LGPL and how I should implement the helper app it into my code.

Since the helper app is personal and wasn't written *for* this project, does the LGPL require I distribute that code along with my Qt code (contract with client aside)? Right now I'm using QProcess to access the helper app executable, which is working perfectly -- however that requires distributing the executable along with the deployment of my app, so I'm trying to incorporate the code into my project (and running into many issues). I can also convert it to a library and deploy with that as well. If the LGPL doesn't require me to deliver the code behind either the .exe or library, then I'd like to skip the whole debugging headaches I'm running into when I added the helper app code to mine.

Kodi

amleto
27th June 2012, 18:15
look at it this way - it doesnt matter how you use that helper app, it is going to get used in your app, or by your app one way or another. As part of the contract, that helper app code is necessarily going to be included.

LGPL requires that your thing be rebuildable with a different version of the library licensed with lgpl. So no, lgpl never requires you to release *source code* (unless you modified the library). Due to the terms of the contract, the code will still have to be released, though so not sure what the point in your question is.

wysota
27th June 2012, 18:50
First of all, LGPL is not a "transient" licenese (as opposed to e.g. GPL) -- using a LGPL component doesn't enforce anything on your app. You are only obligated to make sure the licence of the LGPL component is satisfied (which indirectly might enforce some limitations on your program). Also note that licenses such as GPL and LGPL are focused on what happens if you distribute the component in question. If using your helper app with the main app is optional then you are not in any way forced to release neither the binary nor the source code of your helper app. If the helper app is required for the main app to work (regardless how the technical side of using it looks like) then it counts as part of the project and you should hand it over to the client.

mtnbiker66
27th June 2012, 20:15
The point of my question was if my helper code had to be included per LGPL (ignoring any contract with the client) -- if no, then I was going to have my code just call either the help app as a .exe via QProcess or a library. If I need to include the code from it I may as well fold the code into my project and make one deliverable...

Thanks!

Kodi

Added after 5 minutes:

Yep, it's going to be required by my app so that answers the original question (and is what I pretty much thought would be the case and was hoping to not be), but now I'll have to decide whether to fold the code into mine, or deliver a .exe/library and deliver two sets of code in the end...Probably should do the former, but I have symbols(s) not found errors :)

Thanks, all!

ChrisW67
27th June 2012, 23:27
I am still unsure exactly which components of the end system are covered by the LGPL.

As far as I can see your application is a the subject of the contract and all the source belongs to the client. This has nothing to do with the LGPL.

Your friend's application is closed source, also nothing to do with the LGPL. Whether you have to deliver the source to your client depends very strongly on the scope of the contract you have and what the client already has. For example, if they already licence your friend's application in binary form and your application only calls that pre-existing program (using QProcess) then your friend's program is not your problem.

As with all contractual issues please seek professional legal advice.