Open Source Stack Exchange is a question and answer site for people organizing, marketing or licensing open source development projects. It only takes a minute to sign up.
Sign up to join this community
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.
The preamble to the LGPLv2.1 has a good warning:
Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run.
If an Apache 2.0-licensed software is linked to and is dependent on a LGPLv2.1-licensed library, then it's a "work that uses the library", which is not subject to the terms and conditions of the LGPLv2.1, according to section 6 of the LGPLv2.1:
As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.
If a LGPLv2.1-licensed software or library is linked to and is dependent on a Apache 2.0-licensed library, then the combination of the two is a "work based on the library", and is therefore subject to section 2 of the LGPLv2.1 which states that the combination or the whole, is licensed under LGPLv2.1:
But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
The Apache 2.0-licensed library itself, when used in this latter combination, would be licensed under the terms of both the Apache 2.0 License AND the LGPLv2.1 simultaneously.
The Apache 2.0 License imposes patent-related terms and conditions (in sections 3 and 9) which the LGPLv2.1 does not have.
Section 10 of the LGPLv2.1 states:
You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
So, the Apache 2.0 License conflicts with LGPLv2.1, because Apache 2.0 has additional terms and conditions on patent, while LGPLv2.1 does not allow imposition of further restrictions.
This is why a LGPLv2.1-licensed software or library cannot be linked to and be dependent on a Apache 2.0-licensed library, unless the LGPLv2.1-licensed software or library is licensed as "LGPL version 2.1 or later", in which case the combination can be relicensed under LGPLv3 or GPLv3. The Apache 2.0 License is compatible with LGPLv3 or GPLv3.
If the LGPLv2.1 software or library is licensed as "LGPL version 2.1 only" (and no later), then the combination can be relicensed under GPLv3 based on Section 3 of the LGPLv2.1. The Apache 2.0 License is compatible with GPLv3.
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
