Does LGPL allow Pro / Enterprise versions of the same library?

Question

I have a good understanding of GPL, LGPL, dual-licensing, etc. However I have a specific doubt about the meaning of "linking" in the LGPL.

Suppose that:

1. The library is released under the LGPL
2. You are not the original copyright holder (or not entirely the owner, due to contributions received under the LGPL)
3. You want to sell a Pro / Enterprise version of the library under a commercial license

This is clear: if you need to modify the source code of the library, then you cannot release it under a commercial license (LGPL clearly covers the derived work - i.e. the Pro / Enterprise version).

However, what if the Pro / Enterprise version only "imports" / "includes" / "requires" the community version, without modifying its source code? In that case, can I use a commercial license for the Pro / Enterprise version and say that the LGPL does not apply to the new code?

Note: I use the word "import", "include", "require" because I am talking about languages like Javascript, PHP or Ruby that don't have the concept of "linking".

Answer 1

The LGPL ensures that the library will always remain under the LGPL. Since you are not the sole copyright holder, you cannot relicense the library under a different license.

However, this does not prevent linking the LGPL-covered library with a proprietary library, which is then sold. It is also permissible to bundle the LGPL library with the proprietary library, assuming all other provisions are complied with (corresponding source code, no additional restrictions for the LGPL component, ability to use the library with a modified LGPL component, and so on).

So this kind of architecture is perfectly fine:

However, this assumes that the proprietary wrapper is clearly a different creative work, and is not derived from the LGPL library in the sense of copyright law. In your scenario, the proprietary component only adds new code. But that new code might still be derivative, or may actually form a single program with the LGPL library. This could e.g. be the case if the proprietary component accesses internal data structures of the LGPL library.

The important part is that the LGPLv3 only exempts “applications” from the usual GPLv3 conditions, where an application is defined as “any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library.” As long as the proprietary library only interacts with the LGPL component through the LGPL's component's interfaces, things should be allright. E.g. it would be fine to import the LGPL component and use the resulting objects, but it might not be fine to override object prototypes or to monkey-patch the LGPL library's interfaces to insert hooks for the proprietary wrapper. Ultimately, what constitutes a derivative work is not entirely clear but would be for a court to decide.

Answer 2

The GNU LGPL is the same as the GNU GPL, but it allows inclusion in a non-GNU GPL-licensed application. But the library itself has to still be available under the terms of either the GNU GPL or the GNU LGPL.