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,147

5 Answers5

27

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,352
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,352
unholysampler
  • 7,853
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

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,361
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