19

I am planning to develop a commercial software using a LGPL software.

In the LGPL software that I am using some functions in a class are not fully implemented. I want to modify the LGPL code so that the class and not-implemented functions are made visible outside the dll by adding dllexport infront of class and by adding virtual keyword infront of function.

Then I plan to implement those functions in my proprietary software. I am ready to distribute the modified LGPL code but not proprietary software that implements functions in the way I want.

Does that violate LGPL terms and conditions?

Daenyth
  • 8,077
  • 3
  • 31
  • 46
  • http://stackoverflow.com/questions/3447077/modifications-to-lgpl-code-am-i-documenting-it-correctly – Dipan Mehta Feb 24 '12 at 05:15
  • 6
    The problem with your question being here is that you aren't trying to use the license in the spirit it was written in. We can probably answer questions about the intended meaning of licenses, but we can't get into legal details at all reliably. For that, we can only recommend a lawyer. Moreover, what you're doing depends on a legal question (what is a derived work of the LGPLed software?) that hasn't been settled in the US in case law, and I've seen differing opinions among real lawyers. (I'm not a lawyer, but I've been casually following these problems.) – David Thornley Feb 24 '12 at 21:07
  • Hard to say. Read this: http://www.javalobby.org/java/forums/t15903.html - they're talking about Java, but it seems applicable to any OO language. – Mike Baranczak Feb 24 '12 at 21:16

5 Answers5

28

This is a complex question, but I believe that what you propose is not allowed.

You are suggesting adding hooks into the library to make it easier for you to sub-class the library and thus, at the very least. to bypass the spirit of the LGPL.

The problem is, if you sub-class a class which is subject to the LGPL license in your own code, then your work becomes a work based on the library, rather than a work which uses the library which means that your code is a derivative work that is covered under section 2 (LGPL v2.1) rather than one covered under section 6 (LGPL v2.1). I.e. it becomes subject to the LGPL!

I think that Stephen Colebourne provides a good summary over on javalobby.

I'm not a big fan of knee-jerk talk to your lawyer suggestions, but in this case I think it would be well worth doing so if you plan to proceed with this, otherwise you might be getting a nasty letter from the Free Software Foundation legal team.

Alternatively, you could ask the FSF directly. From their contact page:

For questions about free software licensing and copyright

Please check our licensing FAQ, the license list, general copyleft information, and related pages. If questions remains, email <licensing@gnu.org>.

Incidentally, in the related question Reflection and the LGPL, gbjbaanb answers with the LGPL 3.0 perspective.

Community
  • 1
Mark Booth
  • 14,214
  • 3
  • 40
  • 79
  • 4
    I like "the ask the FSF" suggestion – ZJR Feb 24 '12 at 23:57
  • My reading was that they wanted to expose more functions in the LGPL lib. So long as the resulting lib is still LGPL and a user of the OP's software is free to replace the lib with their on build - I would be happy – Martin Beckett Feb 25 '12 at 05:15
  • 3
    @MartinBeckett - Not quite, the questioner is trying to circumvent the LGPL by modifying the library to make it easier for him to surreptitiously modify the library in his closed source code. If he were adding his new library functionality to the LGPL directly and then using that in his own code, there would be no problem. It's the fact that he's trying to keep his own new functionality closed source yet still part of the library, that's the problem. – Mark Booth Feb 26 '12 at 11:33
  • 6
    [LGPL 3.0](http://www.gnu.org/licenses/lgpl.html) states: "Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library." So this should be allowed, at least under LGPL 3.0. – David Mar 01 '12 at 13:02
  • 3
    @David - I believe that by modifying the LGPL library to allow you to override a function which couldn't normally be over-ridden you are tacitly acknowledging that your code is sufficiently tightly coupled that it has as a 'based on' rather than a 'used by' relationship with the library, so the weak copyleft activates. – Mark Booth Mar 01 '12 at 13:31
  • @MarkBooth The **license text** itself explicitly states that this is a "used by" relationship. Therefore, we do not need to go further into the "tacit acknowledging" territory, which we would have to do if there was some ambiguity. The OP has to provide the source of the LGPL'd library including their modifications to it, which are also under the LGPL, along with any binary they distribute. That is all. There is no concept of how tightly libraries are coupled in any of these licenses. (It would have been nice, though, if the licenses talked explicitly about files as the units of granularity.) – Evgeni Sergeev Mar 05 '16 at 10:49
  • Whilst I value your opinion @EvgeniSergeev, I'm not sure how your comment can help me improve my answer. Do you have any references for your assertion, if so I suggest that you write your own answer here and I will happily vote on it. I certainly believe that the question posed is in a legal grey area, and no definitive answer can be given other than seek legal advice. – Mark Booth Mar 07 '16 at 11:24
15

Standard I am not a lawyer disclaimer.

LGPL requires modifications to the library source code to be distributed to anybody that used your code. It does not require that your code, which uses the library, be open-sourced and released under the same license.

Wikipedia for a more detailed, but non-lawyer description of LGPL, including a section on class inheritance.

Mark Booth
  • 14,214
  • 3
  • 40
  • 79
unholysampler
  • 7,813
  • 1
  • 30
  • 38
  • +1. To summarize: we think it does not violate LGPL (but IANAL) – MarkJ Feb 24 '12 at 05:04
  • @MarkJ - As I explain in [my answer](http://programmers.stackexchange.com/a/136773/22493), I'm not sure that as posed, the question is simply a matter of class inheritance. – Mark Booth Mar 01 '12 at 14:18
  • 10
    I think people just like typing IANAL because it contains "ANAL". – g33kz0r Apr 02 '13 at 21:25
5

"I want to modify the LGPL code ..." this says enough that you must release any of that modified code. Then extending whether or not extending that modified code is a derivative work is up for contention and if so it becomes subject to the LGPL.

What it appears you are trying to do is circumvent the LGPL, which in this case with these techniques you can't.

If it is a derivative work, then the program's terms must allow for "modification for the customer's own use and reverse engineering for debugging such modifications." Whether a work that uses an LGPL program is a derivative work or not is a legal issue.

But if what you are trying to do is circumvent the LGPL I would contact the FSF as recommended by Mark Booth.

Community
  • 1
  • 1
    The problem is, the LGPL allows *some* forms of derived works, while disallowing others. I've updated [my answer](http://programmers.stackexchange.com/a/136773/22493) to make a distinction between derived works that fall under the category of *work based on the library* (which required to be LGPL) and *work which uses the library* (which doesn't). – Mark Booth Feb 27 '12 at 11:15
  • 1
    @MarkBooth I agree with you and others, that in this case it is `work based on` since they are making changes to LGPL in order to expose previously private code. –  Mar 01 '12 at 14:40
1

My guess: (but IANAL) you should release as open source the modified library as LGPL code and then drop it in a commercial program. That would work. Effectively you'd end up having an open source fork of the library around and then you'll be selling a front end for it.

But as many others rightfully said, ask the FSF: it's an intriguing patological scenario you have there; they could be wondering as much as you do if it's applicable or not. (or at least bother about it enough as to publish a FAQ entry on the topic)

ZJR
  • 6,301
  • 28
  • 36
1

https://www.gnu.org/licenses/lgpl-java.html

If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL. Your application's license needs to allow users to modify the library, and reverse engineer your code to debug these modifications. This doesn't mean you need to provide source code or any details about the internals of your application. Of course, some changes the users may make to the library may break the interface, rendering the library unable to work with your application. You don't need to worry about that—people who modify the library are responsible for making it work.

In short, there is no problem with inheritance as long as you do not change the library code itself, but even if you change it, you are required to release only the library modified code, not your application code.

The Storm
  • 21
  • 3
  • 1
    Your answer contradicts several other answers but does not provide much to back your claims. Other answers are more detailed and do a better job of explaining their assertions. Please [edit] your answer to provide relevant quotes from the license or the FSF in order to back your claim. –  May 02 '15 at 12:51
  • How actually my answer does not provide much to back my claims? I had put link to official GNU page that clears the confusion about LGPL and class inheritance. It is even updated to cover LGPL v3. – The Storm May 03 '15 at 19:55
  • 1
    See also: http://meta.stackexchange.com/questions/225370/your-answer-is-in-another-castle-when-is-an-answer-not-an-answer –  May 04 '15 at 00:37