Hey,

I have been developing a project that uses a LGPL-licensed library. Recently I have thought of the possibility to make it a commercial product, to possibly get some compensation for the efforts put in to it. It is a toolkit that is aimed for game developers to make the workflow for creating certain types of graphical assets easier. The toolkit makes extensive use of the library and also part of it is a graphical interface which makes using the library's features easier.

The sources for the toolkit and the library would be provided to the customer when they purchase it, but I would like that my sources for the toolkit would not have to be under the LGPL-license so it would be reasonable to sell it.

The library itself is not modified and it would be provided as source files along with the toolkits sources, or possibly as a dynamically linked library if necessary.

I searched and read previous posts about using LGPL, but I was wondering if it makes a difference that I release the sources for the whole project to the customers? I would appreciate some advice on this to be on the safe side before trying to take it further. How does it sound?

Hey,

I have been developing a project that uses a LGPL-licensed library. Recently I have thought of the possibility to make it a commercial product, to possibly get some compensation for the efforts put in to it. It is a toolkit that is aimed for game developers to make the workflow for creating certain types of graphical assets easier. The toolkit makes extensive use of the library and also part of it is a graphical interface which makes using the library's features easier.

The sources for the toolkit and the library would be provided to the customer when they purchase it, but I would like that my sources for the toolkit would not have to be under the LGPL-license so it would be reasonable to sell it.

The library itself is not modified and it would be provided as source files along with the toolkits sources, or possibly as a dynamically linked library if necessary.

I searched and read previous posts about using LGPL, but I was wondering if it makes a difference that I release the sources for the whole project to the customers? I would appreciate some advice on this to be on the safe side before trying to take it further. How does it sound?

Your release of your own sourcecode shouldn't matter as long as you can keep the LGPL portion clearly separate, This question however is better directed at the copyrightholder or a lawyer.

The one important difference with the LGPL lies in "uses / works with" and "depends on / derivative work". The former means pretty much "do what you want" (though you still must allow users to update the LGPLed lib, so the thing that some DRM programmers did with some setup boxes in the past is illegal) whereas the latter means "must be LGPL too, no way out".

Now of course the problem is telling which one it is... which can be very debatable and which possibly not even your lawyer can tell you for sure (though in the end asking the authors of that lib for approval might do the trick).

Are you using dynamic linking or static linking to the library? Because in the former your program wouldn't be affected while with the latter you're required to make your program LGPL. It's the main difference it has against the GPL (which forces the GPL license in either case). Basically the user needs to be able to change the library somehow, regardless of the program.

I'm not a lawyer, etc. though I'm pretty sure this is actually described in the FSF's site.

Are you using dynamic linking or static linking to the library? Because in the former your program wouldn't be affected while with the latter you're required to make your program LGPL. It's the main difference it has against the GPL (which forces the GPL license in either case). Basically the user needs to be able to change the library somehow, regardless of the program.

Dynamic linking alone, however, is not enough, nor is it the exclusive way of using proprietary software with a LGPL library. There is the requirement that you must allow the user to upgrade the LGPL library, correct. However, this could also be done, in theory, by making a set of proprietary, closed source, copyrighted object files available under a license that allows them being linked exclusively in an exactly specified manner, and exclusively for the purpose of replacing a third party LGPL library. Or, you could make the source code (even in obfuscated form) available under a license that does not permit modification or derivative work.
Incidentially, dynamic linking is the easist and most straightforward way to guarantee exchangeability which does just that without needing to recompile or relink, and which conveys fewer "trade secrets" to the casual eye.

What's really decisive is whether the program is something sufficiently stand-alone, or not. For example, assuming that libjpeg and libpng were under the LGPL (hypothetically, neither of them is in reality), one could argue that an image editor such as Paint.Net or a game using them is a stand-alone product using these libraries. It could, in principle, use any other library to do the relatively minor task of loading an image (or just not support png and jpeg at all), and it's not the principal thing the application is doing.

On the other hand, a texture loading library which uses the same two libraries and does little more than loading images from disk and create a texture object would arguably depend on the library or count as derived work. Thus it would necessarily have to be licensed under LGPL, too. Dynamic linking would in this case not be sufficient to bypass the LGPL (that would be somewhat nonsensical, too).

The real problem here is drawing the line, and none of us will be able to do that decisively. It's something that even the copyright lawyer may have trouble with.