1

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.

  1. 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.

  2. 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 ?

|improve this question
  • 1
    Q1: You only have to publish those upgrades if you have users outside of your organization. Is that the case? Q2: "commercial" means in your case "closed source" and not under LGPL? Q3: do your changes add a dependency between the LGPL lib and your lib, so that the LGPL cannot be compiled/linked any more without your commercial lib? Or can anyone still use that modified LGPL lib without buying your commercial lib? – Doc Brown Jan 2 '14 at 12:20
  • Q1: yes, I will distribute under a commercial licence an application that use the LGPL library which itself will use my commercial library. Q2: "commercial" means a fee to use it. The library and independently the main application client may be open or closed source. I have not yet decided. Anyway, the upgrades of the LGPL library will be published, not necessarily my library it will use. Q3: All what is added in the LGPL library will be embraced under #ifdef #endif pragma in the sources. I will publish it in my forked repository with a link in the distribution of the main application. – lalebarde Jan 2 '14 at 13:29
2

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.

|improve this answer
  • Either my main application will be statically linked to the LGPL library, itself statically linked to my library, either all links will be dynamic. But I won't make available the LGPL library statically linked to my library. Here I think I would brake the licence. I think that's clearly the strong difference with the Berkeley licence. – lalebarde Jan 2 '14 at 16:56
  • "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": In this particular LGPL library, there is an exception that authorise static build. So probably it is not a problem. – lalebarde Jan 2 '14 at 17:00
  • "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." Did you mean "disabled" ? Otherwise, I don't understand. – lalebarde Jan 2 '14 at 17:01
  • @lalebarde: make sure everyone else can create a new version of the LGPL lib (for example, a bugfixed version) and replace that lib in your application system. That should be possible even if the one who does this has no copy of your commercial lib. I guess this will not work if the new functionality is covered by some #ifdefs which have to be disabled to make the thing compile on a system without your lib. The better alternative is IMHO what jdv suggested: make your commercial lib a "plugin" of the LGPL lib (no #ifdef s needed, instead determination of your lib is at runtime). – Doc Brown Jan 2 '14 at 17:09
  • @lalebarde: concerning the "static linking exception": well, you asked for LGPL, not for a "somewhat modified LGPL". It would be interesting how this "static linking exception" is made compatible with the LGPL requirement of keeping the related parts updateable. – Doc Brown Jan 2 '14 at 17:12
1

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.

|improve this answer
  • The idea was not to be unfair. Of course, I will propose to set a pull request to the devs of the library. The point is just to not impose them some functionalities that require an external library that is not LGPL. That's why I was minimalist in saying I will publish it in my fork. – lalebarde Jan 2 '14 at 16:40
  • +1, the "plugin functionality" was actually what I had in mind also in my answer. – Doc Brown Jan 2 '14 at 16:56
  • Could you please elaborate on the plugin solution ? Or put some links ? That's a complete new field of knowledge for me. – lalebarde Jan 3 '14 at 16:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.