The FSF claims that GPL v2 is incompatible with Apache 2.0 and that linking to a library generally creates a derivative work of this library.
However, the linking exception of the LGPL allows linking from an Apache 2.0 software to a LGPL 2.1 library.
Without entering in the debate whether FSF's interpretations are correct, would the converse, linking from a LGPL 2.1 software to an Apache 2.0 library, be allowed?
License compatibility is a one-way street. If A-licensed software can link to B-licensed software, this does not imply that linking in the reverse direction is allowed.
The LGPL-2.1 has one-way compatibility with the GPL-2+:
- You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices.
You can therefore only license code under the LGPL-2.1 if you can also license it under GPL-2+.
The incompatibility of Apache-2 and GPL-2 is well documented. If your software is a combined/derivate work with/of Apache-2 software, you cannot license that software under the GPL-2 and therefore cannot license it under the LGPL-2.1 either. I wish the LGPL would have made this relationship clearer, and the LGPL-3 does clarify this.
Note that the LGPL-2.1 is permissive only with regards to software that uses this library, which is defined as:
- A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
I.e. this permissiveness only applies to downstream works, not to upstream works like an Apache-2 library that your software uses: the upstream dependency is neither derivative of your library, nor was it designed to work with your library.
The GPL FAQ item What legal issues come up if I use GPL-incompatible libraries with GPL software? mentioned by Philippe Ombredanne discusses that you can provide an exception to the GPL-2 for linking with incompatibly-licensed upstream libraries, provided that you are the copyright holder. It is reasonable to believe that this can also be done for LGPL-2.1 licensed software, and that these exceptions would not affect the GPL-2 compatibility in section 3: the exceptions would survive the license change.
If the copyright owners of an LGPL-2 licensed software explicitly add an incompatible dependency, this could be interpreted as an implied license exception. However, you should avoid relying on implied licenses since they might not be accepted in all jurisdictions.
I disagree with the interpretation that absent an explicit exception, you could add an incompatible dependency without being the sole copyright owner. You do not have the right to issue an explicit or implied exception since you are bound by the terms of the LGPL-2, so you cannot add an incompatibly-licensed dependency. If there are examples existing libraries that have done this, these do not provide a precedent that would allow you to ignore the terms of the LGPL-2.
This is a gray area of sorts: let me first reformulate the question a bit to support my points:
Can copyleft-licensed code depend on non-copyleft-licensed code that is using a license that is deemed incompatible with a given copyleft license?
Ok, now this new question is much easier to answer!
For instance, say I am writing an LGPL library in C/C++ to run on Windows and therefore depends on some non-free Windows-based framework libary and APIs. I am ignoring entirely here if the Windows licensing allows this or not (there many MSFT licenses that may restrict this).
There the FSF GPL FAQ is clear
Can I write free software that uses nonfree libraries?
If you do this, your program won't be fully usable in a free environment. If your program depends on a nonfree library to do a certain job, it cannot do that job in the Free World. If it depends on a nonfree library to run at all, it cannot be part of a free operating system such as GNU; it is entirely off limits to the Free World. So please consider: can you find a way to get the job done without using this library? Can you write a free replacement for that library?
So the FSF consider this to be OK but not something they like.
In practice, for instance in the Java world, it is quite common to have an LGPL-licensed package that depends on Apache-licensed packages.
Now reading further:
What legal issues come up if I use GPL-incompatible libraries with GPL software? If you want your program to link against a library not covered by the system library exception, you need to provide permission to do that.
So even though the LGPL is not the GPL, I would say that the best way to do this would be to follow the guidelines provided at the FAQ and license your LGPL library with an exception stating that this does not extend to the Apache-licensed dependencies. Something similar to OpenSSL exceptions commonly found in several places such as here.
Now what if the LGPL-licensed library is not yours and you cannot grant such exception?
I think this is OK. This falls in the FSF GPL FAQ case I mentioned above. Not great but OK. As an example this somewhat popular dbunit java library is LGPL-2.1-licensed without any exception and depends explicitly on Apache-licensed libraries such as Apache Ant and other. This is not great but nobody would object. When I am confronted with such cases I make sure that the dependents are all open source and that when I redistribute I bundle the source code for both the LGPL and its dependencies at full depth.
From the compatibility matrix in the GPL FAQ, we find that the LGPLv2.1-only and the LGPLv3 are incompatible licenses. If code from software licensed under one of these licenses is copied to software licensed under the other license, the resulting combination must be licensed under GPLv3, according to the compatibility matrix.
Modifications of LGPLv2.1-only code must be licensed under the same license or GPLv2+. Modifications of LGPLv3 code must be licensed under the same license or GPLv3+. Hence the combination of the two must be licensed under GPLv3.
But it's different for the case of libraries.
There's no issue if an LGPLv3 licensed library is used by an LGPLv2.1-only licensed software, or vice versa, according to the same compatibility matrix.
So it looks like a software licensed under an incompatible license, may be used as a library, by an LGPLv2.1 licensed software.
Hence, an Apache License v2.0 licensed library may be used as a library by LGPLv2.1 licensed library/ software. They must be separated components that can be linked to each other.
Looking into the LGPLv2.1 license text, I surmise that the following section supports this:
- You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things:
a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above.
b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work.
OpenSC's libp11 is an example of an LGPLv2.1-licensed library that is dependent on and linked to, OpenSSL, a library licensed under the Apache License v2.0. As far as I can tell, libp11 fulfills the conditions of Section 7 of the LGPLv2.1, in linking to OpenSSL.
I read the last sentence as build LGPL2.1 software by using an Apache 2 library.
If that is the right reading then: https://www.apache.org/licenses/GPL-compatibility.html, quote "Apache 2 software can therefore be included in GPLv3 projects"
As GPL3 is much more exclusive LGPL and this the official Apache site the answer is a:
yes
