I am using a LGPL v3 library and have made upgrades to it. Before using these upgrades, I understand I have to publish them. That’s al-right.
-
Is it legal if I perform upgrades that use a commercial library of
my own (upgrades will be published, but not my commercial library)? Note: usually, questions are the other side: commercial applications that want to use GPL libraries. -
If yes to (1), is there some restrictions on the build of the upgraded LGPL library ? Shall the commercial library be dynamically or statically linked, or whatever ?
3
First, the necessary IANAL disclaimer. IMHO the LGPL cannot force you to publish working code. Lets assume you would publish a new version of that lib and introduce a new bug. There is no obligation for you to fix that bug (at least, not from the LGPL itself, maybe you have a contract with your customers, but that’s a different question).
Now let’s assume further that this “bug” is of a nature that the lib (or the features you have added) only works when your commercial library is available on the target system. This does not make a big difference to the first situation, there is still no obligation to publish your commercial part. There is a risk of making your fork unpopular, but I don’t think it will become illegal this way.
However, AFAIK one core point of the LGPL is that end-users should be enabled to update the LGPL-covered parts of the application system you are publishing, without any restrictions. This probably won’t be possible if your deployed version of the LGPL library is statically linked against anything you don’t publish to the world. So if you want to avoid a license breach, you should make sure that after your modifications, others can still compile the LGPL lib in a form which is “enabled” for working together with your commercial lib, even when they don’t have a license for your commercial lib.
5
I do not find the LGPL conclusively denying or allowing the scenario you describe.
It does sounds somewhat against the spirit of the LGPL.
Wouldn’t it be a better solution if you refactor the LGPL code such that you add interfaces that allow you to plug in your proprietary functionality? This may benefit others with similar requirements.
This would be also to your own benefit if your patch is accepted by the library’s maintainers: you don’t need to merge your fork of the library with later revisions of the library.
3