9

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?

|improve this question
4
+100

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+:

  1. 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:

  1. 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.

|improve this answer
  • There is a possibility that LGPL-2.1 section 5 should be interpreted differently: Since the Apache-2 library was designed to be linked with any software, it was implicitly also designed to link with the library in question and is therefore a “work that uses the library”. However, this interpretations seems rather sophistic and would contradict the more obvious meaning of the section. I would therefore recommend not relying on such an absurd interpretation. – amon Jul 20 '17 at 12:53
4

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.

|improve this answer
  • Thanks but if that were my library I would rather license it under LGPL 3.0+. In the case I'm considering upgrading the license or adding an exception to it would be a very hard job (to get an agreement from all copyright owners). – Zimm i48 Jul 19 '17 at 17:57
  • 1
    let me update my answer! – Philippe Ombredanne Jul 19 '17 at 18:01
  • 1
    I always interpreted the first FAQ you refer to more as a philosophical answer than a licensing answer. But it's good to know that there are widely used libraries which fall in that case. It would be an even better confirmation there were examples of such libraries being used by a large and risk-adverse corporation. – Zimm i48 Jul 19 '17 at 18:34
  • @Zimmi48 what about JBoss? github.com/wildfly/wildfly/blob/master/pom.xml#L119 this is LGPL and depends heavily on Apache-licensed code and is wildly used by large and risk-adverse corporations afaik? – Philippe Ombredanne Jul 19 '17 at 21:21
  • That's a good example, with the limitation that it is LGPL 2.1+ so risk-adverse users could always decide to follow the terms of LGPL 3.0. But I'd say that it being developed by RedHat is alone a good sign. – Zimm i48 Jul 20 '17 at 0:05
-2

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

|improve this answer
  • 1
    The compatibility of Apache 2.0 with LGPL 3.0 / GPL 3.0 makes no doubt but the question is specifically about LGPL 2.1. – Zimm i48 Jul 14 '17 at 12:39

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.